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 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. Uers don't care whether you have a CO, a modular architecture, or whatever magic inside Etoile. They need something which works. I only pick the ones which has flexible license, like BSD, MIT, Apache. If people don't like it, then just rewrite them. But until then, I will port as many applications as possible if they are useful.
Yen-Ju On 7/27/07, Günther Noack <[EMAIL PROTECTED]> wrote: > Hi! > > Are you going to drop Grr maintenance, or are you going to integrate > both? The short answer is 'I don't know yet'. There are a lot of issues we need to discuss. There are three components from Vienna: RSS parsing, data storage and UI. I plan to separate them, but not sure in which combination. (RSS Parsing and 'data storage+UI' or 'RSS Parsing+data storage' and UI). StepChat may want to support 'Atom on XMPP'. In that case, the RSS parsing need to be in a framework, maybe mered in RSSKit. David mentions the NNTP support in NewsStand, which is interesting but may need some adjustment on UI. In a broader scale, Jesse propose the 'Inbox' idea, which is related to the 'Object Manager'. It is something we don't have a solid idea yet. On the other side, Apache 2.0 is not compatible with GPL 2. So it increases the complicity, especially for code merge. I think we are at the point where we cannot just talk, but need to find a way to do whatever we want. It will define what Etoile is. For people who want to have a document-centric environment, they need to look at Typewriter and Sketch and propose a way to do so, maybe finish up NSDataLink in GNUstep. For object management, we have AddressManager, Grr/NewsStand, OuterSpace and probably including StepChat. How we are going to make them integrated is a very interesting question. At window management level, most technique details has been figured out. But how we really want to manage windows is still not very clear. On 8/9/07, Guenther Noack <[EMAIL PROTECTED]> wrote: > Hi! > > On Fri, Jul 27, 2007 at 02:25:49PM -0700, Yen-Ju Chen wrote: > > So going back the the Grr issue. > > NewsStand has a better RSS parsing than RSSKit, > > but since it is an application, all RSS-related classes are scattering > > around. > > It may be easier to merge them with RSSKit interface for others to use. > > If that is the case, I might need your permission to change license > > since Apache 2.0 is not compatible with LGPL 2. > > For storage, NewsStand use sqlite3. > > There are always pros and cons with any storage. > > So I will leave this issue to another discussion. > > The only thing I want to be sure is that any storage in Etoile > > needed to be able to be indexed and searched by a 3rd-party application. > > Therefore, they need to have an open interface, > > either from the data itself (XML or sqlite3) or a framework (like > > Addresses). > > On the UI part, there are many small UI classes from > > NewsStand which can be reused, but nothing critical. > > They are just a combination of NSOutlineView, NSTableView and NSTextView. > > That is the least thing I am worry about. > > Here's my opinion on that: > > I spent way too much time on Grr that I could be happy with you adopting > Vienna instead of Grr. Of course I am biased on that, but from my first > look at Vienna I believe that Grr is much more modular. (Of course this > doesn't mean Vienna is a particular poorly written application.) > > I understand that shared application databases are a great vision of > you. Anyway, this vision doesn't conflict with the Grr architecture. You > probably remember that I specifically designed Grr so that you could > replace the "database module" by your own. (SQLite could be a bit harder, > as it's a OO interface to the backend, but in theory even that is > thinkable.) The current database module stores things in .plist files. > > The only reason I made the Grr database module structure this modular > was to allow *you* to try out your vision of shared data across > applications. I wonder why I spent my time on this if you don't use it? > > I hope to find an agreement which involves a future use for the Grr > code in Etoile. > > -Guenther > > _______________________________________________ Etoile-discuss mailing list [email protected] https://mail.gna.org/listinfo/etoile-discuss
