Le 4 févr. 09 à 20:13, David Chisnall a écrit : > 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.
ok. > 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. Well, I see your point. It's difficult to compare CO vs AB vs Sync Services though. They all solve the same problem with a "generic object model". API issues put aside, CO and AB are more friendly, because you only interact with real objects rather than pieces of data exchanged based on an abstract schema you specified in a property list. CO and AB also don't force you to write your schema in a property list, that's nice. So if Apple was going to only offer access to contacts through Sync Services, it would be really unfriendly. They could use Sync Services DB as a storage backend for AB… Cheers, Quentin. _______________________________________________ Etoile-dev mailing list Etoile-dev@gna.org https://mail.gna.org/listinfo/etoile-dev
