On Mon, 2011-03-07 at 08:09 -0800, Arjan van de Ven wrote:
Hi Arjan,
> PIM storage
> ===========
> The Address book, Calendar data and Email are currently stored in a
> tracker database, and accessed (officially) via a QtMobility API set.
> There are a range of issues with this implementation, starting with the
> complexity of adding privacy controls, the performance and
> scalability as well as the completeness for doing a proper syncml sync.
That's great!
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?
> Because of all these items and the available expertise, we have decided
> to start replacing PIM storage with the Evolution Data Server.
Ah, I see.
> 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.
Are you planning to support or implement a QSparql backend for EDS?
I'd be thrilled to have a query language like or as powerful as SPARQL
in EDS! In what timeframe can we expect this? Are you planning to use
existing SPARQL endpoint technology for this? Which?
> But to avoid setting precedents, the lower level components will
> be removed from the architecture diagrams effective immediately.
>
> To be clear, this does not mean that "tracker" is completely removed;
> tracker is still being used (together with tumbler) for indexing media
> on the device. At this point we are seeing serious issues
> (performance/stability) with this solution, but the first attempt will
> be to fix the
> deficiencies rather than a replacement.
At this moment is Tracker (via QSparql and earlier but deprecated
libqttracker) used on Harmattan within quite a wide variety of
(horizontal) applications.
Are the plans to only use Tracker for indexing? That's a fairly small
use-case of Tracker on Harmattan nowadays. Fremantle's metadata solution
of course had an almost exclusive focus on file metadata (indexing). But
that's not the case on Harmattan. What's the plan for those apps?
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
