On 5/8/07, Quentin Mathé <[EMAIL PROTECTED]> wrote: > > Le 8 mai 07 à 07:51, Yen-Ju Chen a écrit : > > > On 5/7/07, Quentin Mathé <[EMAIL PROTECTED]> wrote: > > > > A plan I have is to merge CollectionKit and BookmarkKit. > > Since we probably won't need to maintain AddressKit in the future, > > CollectionKit/BookmarkKit can be more flexible. > > What would be the interest of merging BookmarkKit back into > CollectionKit? Reducing maintenance and unifying APIs even more? > Distinct API looks cleaner to me if you consider it will be used very > often and even in applications that already use CollectionKit in > their own way. > If we use only CollectionKit, how would you support dedicated > extensions? For example, AddressBook has extensions like LDAP support > or ABImageClient protocol. Also it implies we are going to lose Cocoa > compatibility (used by StepChat and others). >
Historically, I want to change Addresses to base on CollectionKit. But GAP will officially maintain Addresses, I see no reason for me to do so again. Actually you can get Addresses in GAP cvs. They just haven't release it officially yet. We can keep a copy of Addresses in our svn just for compliation purpose, but not actively maintain it. It already works O.K. and we have no plan to improve it yet. We might want to have a different UI, but the framework still stay the same. In that case, BookmarktKit and CollectionKit can be freed from Addresses' architecture. BookmarktKit is more used than CollectionKit, but people have to install both of them and they are not really that big. So I figure it will reduce the troubles of installation by merging them. The API will still be very close, say 90% identical. But we can use NSPredicate instead of ADSearchElement. They are redundant in my own opinions. So the functions will stay the same, but the API will be slightly different from Addresses for good reasons. And it is a good chance to change the license. :P Yen-Ju [snip] > > 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
