Hello, > From: Shalamov Alexander > Sent: 15 March, 2011 09:37 > On 03/14/2011 10:20 PM, ext Patrick Ohly wrote: > > I've said before and I say it again here, I consider performance > > comparisons pointless at this time. Doing them badly just reduces any > > good will that might be left from the people one is trying to > convince. > It is not only about performance, strangely nobody mentioned why we > have > "multi-purpose" storage. > Right now we have call history, SMS, IM, MMS, contacts and other types > of data stored in tracker. > > Therefore its very easy to write query like "give me full communication > history for contact A". > Our libcommhistory and commhistory daemon components rely on contacts > that stored in tracker. > > By moving contacts to EDS we will need to change libcommhistory and > commhistory-daemon components > so they will do "cross-domain" queries and we will pay with performance > for that. > > BR, > Alex
Thanks for bringing this up, I tried to ask it earlier in this thread, but it didn't catch fire and I got tired: "what are the test cases both Tracker and EDF (or any other storage) should be measured against? Including horizontal use cases of apps (e.g. building conversation history etc), with constraints on system load, use time, etc." These horizontal use cases were the primary reason Tracker was used for commhistory. Patrick you might remember I explained this when I shared our experiments with a proposed application common database (sqlite vs postgresql), where I also listed our technical requirements towards storages and some example queries. They are mainly covered in the tracker test cases shared by Philip earlier. The conclusion was that contacts, IM [and call history] should share the same database because of the nature of the queries. Since contacts was stubbornly bound to tracker, commhistory had to be in Tracker too. It took a good while to make the performance acceptable with tracker, but once it's done, it looks like it's ditched and someone will have to start that work again. Perfect. Well, I understand that - after 2/11, Nokia's role in MeeGo became somewhat undefined, - MeeGo releases need to roll (thanks Intel) - Intel has EDS competence, but does not have control over tracker - there are performance question marks for tracker in certain use cases = therefore an architecture decision favoring EDS was made in order to be able to move forward in a controllable way. This would be OK, if the decision was made according to the published governance model, if the tracker team was asked about the issues, if there were clear requirements and verification criteria, and if it was clearly outlined how EDS is going to solve the problems Tracker allegedly did not. Questions regarding this have not been answered. That suggests the questions were not even considered (bad), or Intel doesn't even take the burden to answer (bad, suggesting "you pull off, we do our way, bye"). Good luck. I don't know what is the MeeGo governance model today (http://meego.com/about/governance looks to be outdated). What I know is that for any architecture decision it is a MUST to - understand the problem and have clear requirements (this is missing, or not communicated) - understand all dependencies (this is partially missing) - define the target application space (e.g. handset, netbook, automotive, etc) (this was missing, handset scope clearly has different priorities) - have clear verification criteria (this is missing) - consult all stakeholders (this was missing) - present alternative options (this is missing, i.e. how EDS solves the problems (what problems, actually?)) - select one option and stick to it for the given time span (this was done). Please tell me what is the chance this is a good decision? It is not true that the above necessarily takes too long, and the people able to drive it are known. In matters of days a right decision can be made. Could it be that for certain applications EDS is better, and for others Tracker is better? Which and when? If a uniform solution is to be chosen (over a wide range of devices), then which one is chosen? When? As said last time, you made the choice, fine, go and do it. Please make sure you define the missing things from the list above and next time play by clear rules. And someone needs to fork/rewrite/adapt libcommhistory (provided you want a Qt UI), or ditch it too and use something else. Regards, Zoltan
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
