Hello! As those who I have been pestering with questions in the past already know, I'm trying to get an overview of which data we store in MeeGo core and how it can be accessed and/or searched. This email is an attempt to close some gaps and extend the list that I'll present below. I also have some general questions around Tracker.
Typically the answer consists of a domain specific storage and API (mkcal + sqlite) plus Tracker for indexing the data. In some cases, Tracker is also the main storage of the data (QtContacts + qtcontacts-tracker). Sometimes there are additional portability layers on top of the MeeGo platform component (QtMobility Messaging on top of the Qt Messaging Framework (QMF)). The next question then becomes how data items are referenced at the various levels, and how the data content is mapped. For example, can I take the Tracker search results and open the corresponding item using domain specific tools and APIs? This mapping is mostly only defined in the source code which implements the Tracker indexing. I'll provide pointers below. Finally, how can a permanently running app be notified of data changes? Here's what I gathered so far - please extend and/or correct. Mail ==== QMF (gitorious.org/qt-labs/messagingframework): unique 64 bit identifier references each message QtMobility Messaging: a string is used as ID, encodes the QMF integer ID Tracker: NEPOMUK Message Ontology (nmo), meta information pushed into Tracker by MeeGo branch of QMF (gitorious.org/meego-middleware/messagingframework), with nie:isStoredAs holding the 64 bit identifier (if I read the source right: "nie:isStoredAs " << messageUri.uri()) See http://meego.gitorious.org/meego-middleware/messagingframework/blobs/master/src/tools/messageserver/sparqlindexer.cpp Question: what is the current plan for merging MeeGo QMF into upstream QMF? Right now it seems that MeeGo QMF gets rebased regularly on new upstream releases. Why not submit the patches and have one unified code base? Rebasing a public git tree is typically frowned upon; it makes it impossible to clone MeeGo QMF and do downstream development. Question: do change notifications for messages work at each level? How? SMS === Stored in QMF via ofono plugin, so pretty much the same as mail. Contacts ======== QtContacts: QContactLocalId, an integer, change notification via QContactManager signals qtcontacts-tracker: nco::contactLocalUID, a Maemo/MeeGo extension of http://www.semanticdesktop.org/ontologies/nco/, custom QContactDetail mapped to nao::propertyName/Value, fuzzy phone number search implemented by storing normalized phone number in maemo::localPhoneNumber, detailed change notifications via SopranoLive::BackEnds::Tracker::ClassUpdateSignaler QVersit: incomplete (?) subset of QContact See http://gitorious.org/qtcontacts-tracker/qtcontacts-tracker/blobs/master/src/engine/contactsaverequest.cpp Known issue: contact thumbnails are not stored (http://bugs.meego.com/show_bug.cgi?id=5879) Question: are these extensions to the standard NCO documented somewhere public? Question: there used to be documentation in QVersit about the mapping between vCard and QContact. Last time I looked, I only found that in the Google cache. Is that documentation still maintained somewhere? Question: can someone provide an example of a full-featured contact (as many QContact details set as possible, including custom details) and how that is stored in Tracker and a vCard? Calendar ======== QtMobility Calendar: unique ID under debate, see http://developer.qt.nokia.com/forums/viewthread/363/ mkcal: combination of UID + RECURRENCE-ID (optional) + calendar file, change notification only via coarse "calendar has changed" in SqLiteStorage, time zone changes from timed Tracker: NEPOMUK Calendar Ontology (NCAL), pushed by mkcal Sqlite storage, only ncal:uid seems to be set, RECURRENCE-ID is mangled into item ID, detailed changes via SopranoLive::BackEnds::Tracker::ClassUpdateSignaler? See http://meego.gitorious.com/meego-middleware/mkcal/blobs/master/src/trackermodify.cpp Question: serializing a RECURRENCE-ID into a single string is hard because it is a DATE-TIME value + TZID (iCalendar 2.0) resp. a KDateTime (mkcal). What is the recommended way of serializing it? It seems that RECURRENCE-ID is stored in Tracker, but only after conversion to UTC and without milliseconds: // The format supported by tracker is not really ISO8601, as it // doesn't support milliseconds. Therefore we eliminate those here. QString kdatetime2String( KDateTime dt, bool toUtc=true ) Question: ignoring the problem with milliseconds here (doesn't matter for iCalendar 2.0), can mkcal find the original incidence when it has a RECURRENCE-ID using a time zone and the query uses UTC? Media files =========== <disclaimer>I don't know what I am talking about here, even less so than usual...</disclaimer> Files stored in some standardized location, indexed by tracker-miner-fs. NEPOMUK File Ontology. Question: which locations are searched? Which file types are recognized and what information is extracted for each? I'm sure that's documented somewhere, pointers would be enough. Question: do change notifications work here? Usage Information ================= In MeeGo Netbook, gtkrecentfiles is used to show recently accessed items in the MyZone. I've been told that Chrome supports that whereas Banshee doesn't. The corresponding standard is http://standards.freedesktop.org/recent-file-spec/recent-file-spec-latest.html Question: do we use the same mechanism in MeeGo core? It seems prudent to use an established standard (Chrome, Open Office, ...) instead of defining our own. Is there a Qt API for it? Question: the standard doesn't say much about what kind of items are getting stored in ~/.recently-used. Would it make sense to extend the mechanism to also cover interactions with people by defining a URI format and MIME type? Mapping items to apps ===================== Suppose we get nco or ncal items returned via a Tracker search, or such special items in the recent item list. A natural next step is to open the item in the app dedicated to that task. The value of a general purpose query language like SPARQL is reduced if users of it are still forced to encode and fall back to domain specific APIs or apps. Such an app would also not be MeeGo compliant, or at least not very portable (invoking meego-handset-contacts will only work on devices where that app is installed, which is not guaranteed). Question: do we have a mechanism to invoke apps for contacts, calendar, mail, etc. which works across verticals? The corresponding standard is under discussion, see http://www.freedesktop.org/wiki/Specifications/mime-actions-spec We happen to have /usr/share/applications/defaults.list from shared-mimeinfo in MeeGo Trunk, but it doesn't seem to be up-to-date (no Handset apps listed). We have XdgUtils and thus xdg-open in MeeGo Core. I suppose we could extend it to handle special URIs (contact://, calendar://, ...). Tracker ======= Question: does Tracker support a fuzzy full-text search? A general comment: Tracker+QSparql are promoted as a MeeGo API. I'm not sure how application developers are meant to take advantage of this. Are they expected to experiment or read the source code mentioned above to figure out which queries are valid and return results? -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
