On Mon, 2011-03-21 at 20:54 +0100, Patrick Ohly wrote: > On Mo, 2011-03-21 at 17:45 +0000, [email protected] wrote: > > > From: Patrick Ohly, on 21 March, 2011 16:37 > > > In a nutshell, the goal is to keep QtContacts, QMF and KCalCore as the > > > main APIs used by applications and the higher-level QtMobility APIs. If > > > we can achieve that, very little will have to be done in applications > > > once we change the core components. > > > > This will break libcommhistory. > > I'm aware of that, and I don't claim that there is an answer. There is a > task open for those who need libcommhistory (or something like it) to > look into this problem and comment on the current proposals.
Ok, so.. I'll need something like libcommhistory. Check. What are the current proposals for things like libcommhistory? (this is a real question. You're the architect: don't sidestep it again) 1. Support things like IM and call history in EDS? 2. Synchronize contact data in EDS to Tracker's RDF store? 3. Solutions that involve shared memory with EDS? 4. A big drop in messaging performance? 5. A big drop in capabilities? Applications can no longer make queries like these: http://gitorious.net/commhistory/libcommhistory/trees/master/sparql 6. ... 7. Profit? If I know what the proposal is, then I can comment on it. This part is opinion: I find it rather strange. A working solution that does scale well, that performs as good and soon probably better than E-D-S, that supports more use-cases and application domains than even necessary, that is already integrated and very well tested, that has been or is being optimized to meet the performance requirements of each and every use-case and that does support the query flexibility required by applications .. Is being replaced by: o. A solution that needs 20 bullet point task items before even the solution itself actually works. Most of those task items are vague and it's all but clear how they are to be implemented o. that has less support for all the use-cases by its design (being a PIM data -only storage) o. that can not support all application domains unless rather large U-turns are made in the very root of the design o. that has not been optimized for btrfs, as apparently even something as simple as sensible fsync() use is done wrong in E-D-S (see Adrien's measurements on btrfs with and without libeatmydata). https://mail.gnome.org/archives/tracker-list/2011-March/msg00035.html o. A solution that makes all the IPC mistakes possible with D-Bus: o. Passing data, not messages over D-Bus: congestion on the bus o. Passing data marshalled as a DBusMessage instead of FD passing o. Not using D-Bus's signaling mechanism where appropriate o. A solution that has not been tested whatsoever against neither the use-cases, nor the APIs o. Basically, a solution that needs more time to be shaped into something workable ("workable" doesn't mean "works well") than any release time line for a mobile product permits since the last ten years or more. It's strange mathematics. But, ok .. Cheers, Philip -- Philip Van Hoof freelance software developer Codeminded BVBA - http://codeminded.be _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
