> Oh and my exchange contact database contains between 80k and 120k people. that'll take a while...
This extreme example brings up the question: what are the data sets, for netbook/handset/car-set etc, both for typical average usage and extremes for the given category? How should we handle exceptions/out of range situations? And 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. Without setting these first, the data storage story will continue to be a series of bets, trials and failures. Now we just have another new-old bet (EDF), without setting what we want. Not that with Tracker we did :). Then, Philip's questions from below have not been answered yet. Let's define what we want, create a Meego-standardized test bench, make measurements, and decide only then about solutions using EDF/tracker/sqlite/postgresql/graphDB's/whatever. Otherwise decisions alone will not take us anywhere because we don't know where we want to get. Stating that tracker sucks doesn't mean EDF won't. It depends on what you're after. Perhaps you or someone else know, but then please share :). Regards, Zoltan > -----Original Message----- > From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] > On Behalf Of ext Philip Van Hoof > Sent: 07 March, 2011 23:40 > Can you explain us, how does EDS improve privacy control compared to > Tracker's RDF store? Does EDS have a way to represent different graphs > (part of Tracker's future plans to do per-resource privacy control)? > > How in EDS do you say that data (about) x isn't to be made > available to queries made by application y? It's the first time > that I hear that EDS has such a privacy related capabilities. > > Can you also go a bit deeper into how EDS's performance compares to > Tracker's RDF store for comparable data entry operations? Have you guys > done measurements on this? Can the results of these measurements and > the > method to reproduce be publicized? Are the queries you used available > somewhere? Where? > > What do you mean with scalability? Scalable over multiple application > domains other than PIM? Or scalable to more data? And what kind of > data? > I wonder how EDS is or can be more scalable when the underlying > database > technology (SQLite, apparently) is identical. > > In Tracker is each class stored in a decomposed table. This means that > contact and E-mail data are each in separate tables. Although > decomposed > typically makes INSERT a bit slower, SELECT is a lot faster. How will > or > does EDS make SELECT equally 'scalable' with equally complex queries? > > Also note that the Tracker team optimizes both INSERT and SELECT > use-cases on a use-case per use-case basis, using its domainindexes and > indexes. Have you contacted the Tracker team about the scalability > problems (if any)? > > Or is EDS only more scalable during data entry? > > > This change will land together with the SyncEvolution change (due to > the > > intimate relationship between the storage and sync of PIM data). > > This change should largely be invisible to applications since > > applications are supposed to access this data via the appropriate > QtMobility > > APIs. > > That's not entirely true. Many applications are nowadays accessing said > data through the QSparql API of Harmattan. QtMobility isn't always the > ideal access-layer. Especially not for more complex use-cases. >
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
