On Tue, 2011-03-08 at 15:23 +0000, Graham Cobb wrote: > On Tuesday 08 March 2011 12:55:45 Philip Van Hoof wrote: > > But I have the feeling that we won't see *any* numbers whatsoever.
Hi Graham, thanks for your reply > I realise the question was directed at the MeeGo architects but I would hope > that the Nokia product managers for the PIM/tracker developments had > quantitative requirements for performance and scalability. What were they? > Did you meet them? Yes, there are such requirements. I can't make them available publicly myself unfortunately. > If I had been the product manager I would have tried to get requirements in > three ways: > > 1) Put an engineer for a couple of days on testing market leading enterprise > devices (hint, Blackberry). Determine any practical scalability limits > (numbers of events, contacts, emails, etc) as well as performance with large > databases (update, lookup, etc). It's similar. > 2) Ask my own (Nokia) sales people how they actually use their handheld > devices: how many events, contacts, emails, etc they have on their device? > How many different folders they have them divided into? How and why do they > look people up? Do they use a card scanning app on their phone to import > business cards? Do they consider the phone or Exchange to be the master? > What > would happen if you stole their phone now and refused to give it back? Etc. > I am sure the answers would be very different to the way the engineers or > even > product managers use their devices. sure > 3) Ask the network operators what their requirements are: many of them have > pretty clear requirements. Yes, such things take place. Of course. > Nokia used to be the best at understanding and interpreting market > requirements. In the old days, that was not only for the consumer segment > but > even for business (there is a reason the 6310i is still available on eBay > today!). > Are there really no quantitative requirements you can tell us about, Philip? I'm asking for numbers and measurements on EDS in comparison with Tracker. Not only requirements (other people are asking for our requirements, and some requirements can probably be made public -- sure, just not up to me) - The word was that Tracker doesn't perform well enough and therefore it is being replaced by EDS. I'm guessing that means that EDS *does* perform well on identical datasets then? Are there numbers on that conclusion? We are into numbers and technical arguments. Are the methods to reproduce available? We have some performance tests in Tracker's repo publicly available, by the way. For example (just one example, I don't feel like flooding this ML): http://git.gnome.org/browse/tracker/tree/tests/functional-tests/performance-tc.py That test also illustrates some of the levels of query flexibility and domain scalability we need for certain applications. How does EDS compare to those? - The word also was that EDS is more scalable. What does scalable mean? Does it scale over more application domains and use-cases than Tracker? How does that work? Does EDS scale better at query flexibility (can you do more flexible, more powerful queries with EDS)? Does it scale better with large amounts of data? And also in combination with aforementioned query flexibility? - The word also was that EDS must have privacy controls, since for the lack of having privacy controls is Tracker being replaced with EDS. Where is that feature documented? How does that work? Arjan gave legitimate reasons for replacing a technology. But How does the replacement improve things? I think those are reasonable questions to ask given the impact of the decision. I was witness of the Fremantle -> Harmattan days, and what I'm seeing here feels like the exact same mistakes Nokia made being repeated 'in exactly the same way', by Intel. 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
