Okay, I moved to Deprecated: Frameworks/MultimediaKit Frameworks/DistributedView Frameworks/InspectorKit Services/User/Spot Services/User/Babbler Languages/Io
and deleted: Frameworks/OrganizeKit I also removed references to these from the relevant GNUmakefiles. -Eric On Wed, Feb 4, 2009 at 12:13 PM, David Chisnall <thera...@sucs.org> wrote: > On 4 Feb 2009, at 18:48, Quentin Mathé wrote: > >> Hi Eric, >> >> Le 3 févr. 09 à 23:16, Eric Wasylishen a écrit : >> >>> Hi, >>> There are several frameworks which haven't been modified in quite a >>> while, and seem to be superseded by newer frameworks. I'm wondering >>> if >>> I can move these to the Deprecated directory: >>> >>> Frameworks/AddressesKit/ >>> - David was saying that the AddressKit API is poorly designed, and >>> we'll need a new one which uses CoreObject (if we need a framework at >>> all?). >> >> We could use CoreObject API directly, but having a standalone >> framework as syntactic sugar is more friendly. >> AddressBook API also allows us to remain compatible with Mac OS X, so >> I don't know whether it's really a good idea to design our own API. >> It should stay there until it's rewritten since we have nothing else >> to replace AddressManager that relies on it. > > I would like us to have a 'native' interface, which is just a set of > CO conventions and a standard CO location for people. We can then > write an AB compatibility API on top of this, but always view it as a > foreign API, rather than our native address book API. > > I believe compatibility with this API is going to become less > important in future. It's ugly beyond belief, and Sync Services > replicate all of its functionality in a much less brain-dead way on OS > X now. > > David > _______________________________________________ > Etoile-dev mailing list > Etoile-dev@gna.org > https://mail.gna.org/listinfo/etoile-dev > _______________________________________________ Etoile-dev mailing list Etoile-dev@gna.org https://mail.gna.org/listinfo/etoile-dev
