On 7/25/07, Quentin Mathé <[EMAIL PROTECTED]> wrote: > Le 24 juil. 07 à 18:00, Yen-Ju Chen a écrit : > > > On 7/24/07, Jesse Ross <[EMAIL PROTECTED]> wrote: > >> > >> NewsStand is good -- I'd be cool with that. > >> [snip] > >> Okay, here's another direction then. If we make it do Usenet, why not > >> then turn it into a generic "Inbox", something along the lines of > >> what we discussed having a while ago. The interface is the same as > >> what would be used for email and IM messages (not chats, but messages > >> as XMPP defines them). > >> > >> And if it does Usenet (and email and IM messages), should it then > >> also be able to Reply? (Of course, the best way to handle this would > >> be able to have a Reply Service that could be used generically for > >> anything, rather than having to build this into the client itself...) > >> > >> Thoughts? > > > > O.K. I probably will stay with 'NewsStand'. > > As for inbox, I would say there are some things > > we should discuss about implementation. > > For example, Vienna currently use database for storage, > > while I tend to use property list so that I can use > > NSPredicate for searching. > > Or I can just use ETSerializer for storage. > > I do plan to split the GUI part and RSS parsing later. > > I agree with Yen-Ju. Messages/Inbox manager is also just a subcase of > the generic object manager plus a helper component for message > composing/writing (this component is itself a subcase of text editor/ > processor). > However I think OrganizeKit would be a very good choice for the > storage. Yen-Ju, if you are ok with this idea, you could bring a copy > of OrganizeKit inside Étoilé svn and remove CollectionKit. > At later point, I think OrganizeKit could use ETSerializer > (CoreObject) for undo/redo, versioning and checkpointing. Automatic > serialization facility has no use since plist are easy to serialize > without code at all :-) > In my mind, OrganizeKit would be the default storage facility for all > object managers. Finally ETSerializer would be available for document- > based applications when you need or prefer a very fine control over > the model. It may also be used as a custom OrganizeKit backend when > OrganizeKit default backend doesn't scale. > ETSerializer would also be used for stuff like copy/paste and drag/ > drop of any objects accross the environment. > > I plan to write a mail soon discussing integration of ETSerializer > and OrganizeKit in CoreObject context. As it stands now ETSerializer > is part of CoreObject but OrganizeKit isn't. CoreObject name service > will be relatively closed from OrganizeKit API.
I am happy to put OrganizeKit in -trunk any time soon. But there is a critical function missing: transaction. Considering one application read all data in memory and another one modify the same data on disk, then the first application will get notified and merged its data in memory and updated data on disk. I haven't figure out an easy way to do so. If I need to compare data one-by-one between the one in memory and the ones in disk, I think it is kind of slow. That's why I am always wondering whether it is better to find an embedded database for such purpose. This one looks interesting: http://www.dekorte.com/blog/blog.cgi?do=item&id=2783 Yen-Ju > > Cheers, > Quentin. > > > > _______________________________________________ > Etoile-dev mailing list > [email protected] > https://mail.gna.org/listinfo/etoile-dev > _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
