On 8/10/07, Guenther Noack <[EMAIL PROTECTED]> wrote: > Hi! > > On Thu, Aug 09, 2007 at 09:23:36AM -0700, Yen-Ju Chen wrote: > > Below is the short discussion with Guenther, the author of Grr. > > I am O.K. with any choice. > > But I need something which works. > > I understand your point and I agree with everything mentioned below. > However, it's still unclear to me which part of Grr doesn't meet the > "something which works"-requirement? In my point of view, it works quite > well. Do you miss any functionality that Vienna provides? Is it the > license?
License is not an issue. Actually David does not like Apache that much, and Apache 2.0 is incompatible with GPL 2. I believe there is no linking problem. It is just that source codes cannot be mixed. On the RSSKit level, Vienna processes RSS better. For example, some Atom provides a base url and any other link in each article is related to that base url. I believe it is <xml:base> in Atom protocol. It also handle embedded html inside xml better and support various encoding. Embedded HTML is used by many RSS. NSXMLParser in Grr only process XML while HTML may violates XML, ex, <br> instead of <br/>. I use TRXML in this case. While RSSKit uses NSURL for downloading, the real situation is more complicated when redirection is involved. So it is basically like a small web browser which need to talk to server in order to get the real RSS data. In this case, Vienna use NSURLRequest, which only work on GNUstep -trunk. Since it uses NSURLRequest, it can also support downdloading for podcast. RSSKit does has <enclosure>, but not download. On the Grr level, most noticable part is smart folder. Another is OPML. But I would say the most important part is stability. Whenever I use Grr, I just pray it is not going to crash. I know there is a memory leaking somewhere, but I just never found it out yet. Again, what is the future plan ? i don't know yet. I want to fix the user interface of smart folder and info window on GNUstep first. By the time CO is done, we can consider how to integrate them. That's another thing I am thinking for a while but haven't brought it up for discussion, something like the integration on the *object manager* level stuff. Yen-Ju > > > > I am more a pragmatic person. > > All these grand views of Etoile are great, > > but will not come any time soon. > > Take dock as an example, what do we want to have on the desktop ? > > How about the tabbed shelf people discuss before ? > > There are various discussion here and there, > > but we never reach an agreement. > > Very true. Etoile definitely lacks a clear list of goals. The problem > IMHO is that pretty much everything that comed up on the list is agreed > upon, no matter whether it conflicts with any of the previous goals or > not (Dock/Shelf/Whatever). Maybe you should simply make a collection of > the feature ideas, identify conflicting goals and then vote for the > different goals. This would result in a prioritized list of goals. > Etoile simply *can't* implement every single user interface idea on the > internet. You have to drop things to focus on the important aspects. > > At the moment, things only get done when single developers decide to > write them. This may also give good results at first, but it won't > give you a desktop system with integrated, cooperating applications. > > Best regards, > Günther > > > _______________________________________________ > Etoile-discuss mailing list > [email protected] > https://mail.gna.org/listinfo/etoile-discuss > _______________________________________________ Etoile-discuss mailing list [email protected] https://mail.gna.org/listinfo/etoile-discuss
