MeeGo wiki - User contributions [en]

Architecture/planning/evolution-data-server/eds-improvements

2011-06-08T14:29:35Z

Pohly: /* Asynchronous API for storing items in libecal */

This page describes improvements that are desirable or even essential for good performance of Evolution Data Server (EDS) as PIM storage in MeeGo.

All of these changes should be developed for the EDS master branch, reviewed by upstream maintainers and then back-ported to EDS 2.32, the version in MeeGo.

== Change Tracking ==

EDS is based on the model/view/controller principle: an application opens a database (calendar or addressbook) and requests a view with server-side filtering, then the application is sent:
# all data covered by the view
# the "all data sent" signal
# changes (add/update/remove) while the view exists

Applications modify data with asynchronous requests (controller) and keep showing the old data until the change notification comes in. The exact changes made to the data are determined by the server (for example when meeting invitations are sent).

QtContacts and KCalCore do not have such a strict model. With QtContacts the app simply loads and stores contacts and is responsible for maintaining its own view. Changes are sent for changes made after the database was opened. KCalCore is based on the concept of loading a calendar (partially) into the client, modifying it there, then writing it back. Changes are also sent while the storage is open.

TODO:
* https://bugs.meego.com/show_bug.cgi?id=18760 - "QtContacts-EDS + EDS: more flexible EBookView (UID only, only future changes)"

=== Suppress Unnecessary Data Transfer ===

EDS currently sends all data when a view is requested, which is unnecessary when the client is only interested in change notifications. An extension to the EDS query language could optionally suppresses that sending of existing data when the view is opened, to be implemented only for the local contacts and calendar backends. This would allow easier integration with the QContact API.

The Fremantle EDS fork also had a “freezable” (static) capability for libebook, which should probably be investigated. See, for instance: http://maemo.org/api_refs/5.0/5.0-final/libebook/EBookView.html#e-book-view-set-freezable

One possibility for adding the flag is to (ab)use the existing query language with a match for special fields:
* in the client: query = e_book_query_orv(e_book_query_field_exists("X-EDS-QUERY-FLAG-SKIP-DATA-DUMP"), <real query>, NULL);
* in the server: "if (query is OR-Query and first clause is exists("X-EDS-QUERY-FLAG-SKIP-DATA-DUMP")) { skip_data_dump = TRUE; query = second clause; }

=== Return UIDs Only ===

The e_book_get_book_view() function takes a list of requested fields, to avoid returning unnecessary data, but this is apparently ignored for the local contacts backend. It would anyway require extra parsing and generation of smaller VCards, losing some possible advantages from delayed parsing of VCards.

However, the UID is already stored separately for use as the primary key of the BDB database, so it would be worthwhile to support that particular requested field. This would allow easier integration with the QContact API. It would also offer much better performance in cases where the client already has the data but just wants to discover what subset of that data meets a certain criteria.

Chris discovered a dedicated API for this in the Fremantle EDS fork. The new API call was accepted upstream and [https://bugzilla.gnome.org/show_bug.cgi?id=651446#c11 backported as a patch] (used in the Meego package) for the gnome-2-32, so no further work is needed?

== Optional Parsing of ebook Data in Client ==

The EDS client-side APIs currently parse and (temporarily) store the parsed details of VCards. However, this is often unnecessary because APIs such as e_book_get_book_view() cause it to return the whole VCard anyway. There will be some performance gain from delaying VCard parsing until it is really needed by calls to functions such as e_contact_new_from_vcard().

libebook provides different functionality:
# exchange data as vCard with EDS daemon
# parse items and wrap them in a C API

QtContacts replaces the second part. An obvious performance improvement is to only do the second part if the additional C APIs are really called. The following calls then transfer data without any additional parsing in libebook:
* e_book_get_contact()/asynchronous read/view + e_vcard_to_string()
* e_contact_new_from_vcard() + e_book_add_contact()/e_book_commit_contact()/asynchronous storing

Note that libecal (for iCalendar) can already do this, though libebook can't yet.

TODO:
# add delayed parsing to libebook, triggered by API call which needs parsed data

PROBLEM:
# If delayed parsing fails, how can error be reported?
# Should delayed parsing be done always (e_vcard_to_string())) or only if requested? How would that be configured by a libebook user?

An existing (and in use) [http://build.meego.com/package/view_file?file=EBookView-Implement-delayed-vcard-parsing.patch&package=evolution-data-server&project=eds&srcmd5=977d2b885bed818cb616599749407e79 patch] might partly implement this already.

== Asynchronous API for storing items in libecal ==

libecal should allow the caller to request storing of data without blocking on processing of the data. It should notify the caller when the data has been stored, or when processing has failed.

These functions may require async versions:
* icalcomponent_new_from_string()
* e_cal_modify_object[_with_mod]
* e_cal_create_object()

Making libical asynchronous is almost impossible without going multithreaded. Let's focus on e_cal D-Bus communication first.

Rob started some work on this in the rbradford-wip-ecal-async-api branch. Perhaps you can reuse some of that work. It is not functional, but might be a source of inspiration or code fragments.

== More Efficient Access to Meta Data for Change Tracking ==

This was discussed a while ago: [[http://www.mail-archive.com/evolution-hackers@gnome.org/msg03029.html
[Evolution-hackers] concurrent modifications of items in GUI and EDS database]]

Data synchronization only needs to know which items exist (list of local IDs) and which revision of each item is currently stored. Revisions can be identified with a string which changes for each modification. Restoring an older revision should (but doesn't have to) restore the revision string.

For calendar, UID+RECURRENCE-ID and LAST-MODIFIED can be used. For contacts, UID + REV.

By comparing a stored list against the current one, changes can be detected without relying on journals in the daemon or comparison of time stamps. Journals are hard to maintain (how many of them, how long?). Comparison of time stamps has problems when changes are allowed while a sync runs and assumes that system time is linear (which is not always true).

As an additional use case, local ID + revision string could be used to prevent overwriting stale data in the server, as in HTTP PUT eTag checks.

TODO:

The Maemo Fremantle port of EDS, which is of course already open source, apparently has some solution for this, according to Mathias Hasselman, so that should be investigated first.

However, this should probably be made possible by:

# Extending the EDS query language with a flag that limits the delivered data to just:
## UID and REV for libebook (REV is in VCard 3.0)
## UID+RECURRENCE-ID+LAST-MODIFIED, for libecal
# Implementing these queries for the local contact and calendar backends. The query would be rejected, with an error, for other backends.

== Atomic Updates ==

Later, implement atomic changes as discussed in the mail thread: [[http://www.mail-archive.com/evolution-hackers@gnome.org/msg03029.html

== Quick check for "data changed" ==

The libebook and libical APIs should offer a way to discover if any data whatsoever has changed. This would, for instance, help SyncEvolution to avoid unnecessary detailed checking. This could just check the modification dates of local storage files, such as the BDB .db file, or .ics file, as long as we do not use those files to store permanent caches of parsed data. This would be much quicker than listing items for the whole database and comparing their revisions strings, as is currently necessary.

This would require small API additions, to check that the opaque revision strings are unchanged, such as

gchar* e_book_get_revision(EBook *book)
gboolean e_book_check_revision(EBook *book , const gchar* revision)

and

gchar* e_cal_get_revision(ECal *ecal)
gboolean e_cal_check_revision(ECal ecal, const gchar revision)

The semantic would be this:
* If the revision string is empty or different, then the content of the database '''might''' have changed. A more detailed check is necessary to determine if it has really changed. This will be the case for non-local storage.
* If it is non-empty and the same as before, the nothing has changed. No further check will be necessary.

== Contacts: Store PHOTO Data as Plain Files ==

Photos should be transferred over D-Bus via a filepath to a local file rather than transferring the actual photo data over D-Bus. The VCard format already allows this option (See the PHOTO property). We must be careful to keep these local files in sync and to remove them when contacts are removed, and to restrict access to the files from other processes.

There should be utility code available to libebook users to convert between the different representations.

Goals:
# Apps should be able to create photo files without ever passing the data to libebook.
# External PHOTO file and corresponding contact must be kept in sync:
** If a contact is deleted, the photo also needs to be removed.
** If a photo file is created and then storing the contact fails, who removes the file?
# Access to photo data must be limited to processes which have the right permissions.

Proposal:
* For each ~/.local/share/evolution/foo calendar, store photos in <photo path>=~/.local/share/evolution/foo/photos, with same permissions.
* New photo files are created with a [http://en.wikipedia.org/wiki/Universally_unique_identifier UUID] as base name and suffix according to the file content.
* If a contact is deleted and has a PHOTO;VALUE=uri:file://<photo path>/*, delete that file.
* For apps which want to create the photo file directly:
** Apps get a file descriptor and the path from a new libebook API.
** They own the file until the EDS server acknowledges the successful storing of a contact with a matching PHOTO;VALUE=uri:file property. If that fails, the app must remove the file.
* Add new API calls to libebook which split out resp. include data inline.
** Must track ownership of file after splitting it out and before storing - might never get stored!

Open:
* Should there be automatic garbage collection of stale photos in case something went wrong and a photo wasn't properly deleted?
* Trust TYPE=JPEG/PNG/... or look into file content to determine type?

== Future: Content Protection ==

Only authorized applications (= processes) with the necessary permissions should be able to read/write data. Exact permissions and mechanisms for verifying them to be defined as part of the (revised?) MeeGo architecture.

This can be added as follows:
# lock down file permissions
# add permission checks to EDS D-Bus servers

Currently not planned. Depends on the future MeeGo security infrastructure.

Architecture/planning/evolution-data-server/eds-improvements

2011-06-08T14:24:56Z

Pohly: /* Change Tracking */

This page describes improvements that are desirable or even essential for good performance of Evolution Data Server (EDS) as PIM storage in MeeGo.

All of these changes should be developed for the EDS master branch, reviewed by upstream maintainers and then back-ported to EDS 2.32, the version in MeeGo.

== Change Tracking ==

EDS is based on the model/view/controller principle: an application opens a database (calendar or addressbook) and requests a view with server-side filtering, then the application is sent:
# all data covered by the view
# the "all data sent" signal
# changes (add/update/remove) while the view exists

Applications modify data with asynchronous requests (controller) and keep showing the old data until the change notification comes in. The exact changes made to the data are determined by the server (for example when meeting invitations are sent).

QtContacts and KCalCore do not have such a strict model. With QtContacts the app simply loads and stores contacts and is responsible for maintaining its own view. Changes are sent for changes made after the database was opened. KCalCore is based on the concept of loading a calendar (partially) into the client, modifying it there, then writing it back. Changes are also sent while the storage is open.

TODO:
* https://bugs.meego.com/show_bug.cgi?id=18760 - "QtContacts-EDS + EDS: more flexible EBookView (UID only, only future changes)"

=== Suppress Unnecessary Data Transfer ===

EDS currently sends all data when a view is requested, which is unnecessary when the client is only interested in change notifications. An extension to the EDS query language could optionally suppresses that sending of existing data when the view is opened, to be implemented only for the local contacts and calendar backends. This would allow easier integration with the QContact API.

The Fremantle EDS fork also had a “freezable” (static) capability for libebook, which should probably be investigated. See, for instance: http://maemo.org/api_refs/5.0/5.0-final/libebook/EBookView.html#e-book-view-set-freezable

One possibility for adding the flag is to (ab)use the existing query language with a match for special fields:
* in the client: query = e_book_query_orv(e_book_query_field_exists("X-EDS-QUERY-FLAG-SKIP-DATA-DUMP"), <real query>, NULL);
* in the server: "if (query is OR-Query and first clause is exists("X-EDS-QUERY-FLAG-SKIP-DATA-DUMP")) { skip_data_dump = TRUE; query = second clause; }

=== Return UIDs Only ===

The e_book_get_book_view() function takes a list of requested fields, to avoid returning unnecessary data, but this is apparently ignored for the local contacts backend. It would anyway require extra parsing and generation of smaller VCards, losing some possible advantages from delayed parsing of VCards.

However, the UID is already stored separately for use as the primary key of the BDB database, so it would be worthwhile to support that particular requested field. This would allow easier integration with the QContact API. It would also offer much better performance in cases where the client already has the data but just wants to discover what subset of that data meets a certain criteria.

Chris discovered a dedicated API for this in the Fremantle EDS fork. The new API call was accepted upstream and [https://bugzilla.gnome.org/show_bug.cgi?id=651446#c11 backported as a patch] (used in the Meego package) for the gnome-2-32, so no further work is needed?

== Optional Parsing of ebook Data in Client ==

The EDS client-side APIs currently parse and (temporarily) store the parsed details of VCards. However, this is often unnecessary because APIs such as e_book_get_book_view() cause it to return the whole VCard anyway. There will be some performance gain from delaying VCard parsing until it is really needed by calls to functions such as e_contact_new_from_vcard().

libebook provides different functionality:
# exchange data as vCard with EDS daemon
# parse items and wrap them in a C API

QtContacts replaces the second part. An obvious performance improvement is to only do the second part if the additional C APIs are really called. The following calls then transfer data without any additional parsing in libebook:
* e_book_get_contact()/asynchronous read/view + e_vcard_to_string()
* e_contact_new_from_vcard() + e_book_add_contact()/e_book_commit_contact()/asynchronous storing

Note that libecal (for iCalendar) can already do this, though libebook can't yet.

TODO:
# add delayed parsing to libebook, triggered by API call which needs parsed data

PROBLEM:
# If delayed parsing fails, how can error be reported?
# Should delayed parsing be done always (e_vcard_to_string())) or only if requested? How would that be configured by a libebook user?

An existing (and in use) [http://build.meego.com/package/view_file?file=EBookView-Implement-delayed-vcard-parsing.patch&package=evolution-data-server&project=eds&srcmd5=977d2b885bed818cb616599749407e79 patch] might partly implement this already.

== Asynchronous API for storing items in libecal ==

libecal should allow the caller to request storing of data without blocking on processing of the data. It should notify the caller when the data has been stored, or when processing has failed.

These functions may require async versions:
* icalcomponent_new_from_string()
* e_cal_modify_object[_with_mod]
* e_cal_create_object()

== More Efficient Access to Meta Data for Change Tracking ==

This was discussed a while ago: [[http://www.mail-archive.com/evolution-hackers@gnome.org/msg03029.html
[Evolution-hackers] concurrent modifications of items in GUI and EDS database]]

Data synchronization only needs to know which items exist (list of local IDs) and which revision of each item is currently stored. Revisions can be identified with a string which changes for each modification. Restoring an older revision should (but doesn't have to) restore the revision string.

For calendar, UID+RECURRENCE-ID and LAST-MODIFIED can be used. For contacts, UID + REV.

By comparing a stored list against the current one, changes can be detected without relying on journals in the daemon or comparison of time stamps. Journals are hard to maintain (how many of them, how long?). Comparison of time stamps has problems when changes are allowed while a sync runs and assumes that system time is linear (which is not always true).

As an additional use case, local ID + revision string could be used to prevent overwriting stale data in the server, as in HTTP PUT eTag checks.

TODO:

The Maemo Fremantle port of EDS, which is of course already open source, apparently has some solution for this, according to Mathias Hasselman, so that should be investigated first.

However, this should probably be made possible by:

# Extending the EDS query language with a flag that limits the delivered data to just:
## UID and REV for libebook (REV is in VCard 3.0)
## UID+RECURRENCE-ID+LAST-MODIFIED, for libecal
# Implementing these queries for the local contact and calendar backends. The query would be rejected, with an error, for other backends.

== Atomic Updates ==

Later, implement atomic changes as discussed in the mail thread: [[http://www.mail-archive.com/evolution-hackers@gnome.org/msg03029.html

== Quick check for "data changed" ==

The libebook and libical APIs should offer a way to discover if any data whatsoever has changed. This would, for instance, help SyncEvolution to avoid unnecessary detailed checking. This could just check the modification dates of local storage files, such as the BDB .db file, or .ics file, as long as we do not use those files to store permanent caches of parsed data. This would be much quicker than listing items for the whole database and comparing their revisions strings, as is currently necessary.

This would require small API additions, to check that the opaque revision strings are unchanged, such as

gchar* e_book_get_revision(EBook *book)
gboolean e_book_check_revision(EBook *book , const gchar* revision)

and

gchar* e_cal_get_revision(ECal *ecal)
gboolean e_cal_check_revision(ECal ecal, const gchar revision)

The semantic would be this:
* If the revision string is empty or different, then the content of the database '''might''' have changed. A more detailed check is necessary to determine if it has really changed. This will be the case for non-local storage.
* If it is non-empty and the same as before, the nothing has changed. No further check will be necessary.

== Contacts: Store PHOTO Data as Plain Files ==

Photos should be transferred over D-Bus via a filepath to a local file rather than transferring the actual photo data over D-Bus. The VCard format already allows this option (See the PHOTO property). We must be careful to keep these local files in sync and to remove them when contacts are removed, and to restrict access to the files from other processes.

There should be utility code available to libebook users to convert between the different representations.

Goals:
# Apps should be able to create photo files without ever passing the data to libebook.
# External PHOTO file and corresponding contact must be kept in sync:
** If a contact is deleted, the photo also needs to be removed.
** If a photo file is created and then storing the contact fails, who removes the file?
# Access to photo data must be limited to processes which have the right permissions.

Proposal:
* For each ~/.local/share/evolution/foo calendar, store photos in <photo path>=~/.local/share/evolution/foo/photos, with same permissions.
* New photo files are created with a [http://en.wikipedia.org/wiki/Universally_unique_identifier UUID] as base name and suffix according to the file content.
* If a contact is deleted and has a PHOTO;VALUE=uri:file://<photo path>/*, delete that file.
* For apps which want to create the photo file directly:
** Apps get a file descriptor and the path from a new libebook API.
** They own the file until the EDS server acknowledges the successful storing of a contact with a matching PHOTO;VALUE=uri:file property. If that fails, the app must remove the file.
* Add new API calls to libebook which split out resp. include data inline.
** Must track ownership of file after splitting it out and before storing - might never get stored!

Open:
* Should there be automatic garbage collection of stale photos in case something went wrong and a photo wasn't properly deleted?
* Trust TYPE=JPEG/PNG/... or look into file content to determine type?

== Future: Content Protection ==

Only authorized applications (= processes) with the necessary permissions should be able to read/write data. Exact permissions and mechanisms for verifying them to be defined as part of the (revised?) MeeGo architecture.

This can be added as follows:
# lock down file permissions
# add permission checks to EDS D-Bus servers

Currently not planned. Depends on the future MeeGo security infrastructure.

Architecture/planning/evolution-data-server/eds-improvements

2011-06-08T10:49:39Z

Pohly:

This page describes improvements that are desirable or even essential for good performance of Evolution Data Server (EDS) as PIM storage in MeeGo.

All of these changes should be developed for the EDS master branch, reviewed by upstream maintainers and then back-ported to EDS 2.32, the version in MeeGo.

== Future: Content Protection ==

Only authorized applications (= processes) with the necessary permissions should be able to read/write data. Exact permissions and mechanisms for verifying them to be defined as part of the (revised?) MeeGo architecture.

This can be added as follows:
# lock down file permissions
# add permission checks to EDS D-Bus servers

Currently not planned. Depends on the future MeeGo security infrastructure.

== Change Tracking ==

EDS is based on the model/view/controller principle: an application opens a database (calendar or addressbook) and requests a view with server-side filtering, then the application is sent:
# all data covered by the view
# the "all data sent" signal
# changes (add/update/remove) while the view exists

Applications modify data with asynchronous requests (controller) and keep showing the old data until the change notification comes in. The exact changes made to the data are determined by the server (for example when meeting invitations are sent).

QtContacts and KCalCore do not have such a strict model. With QtContacts the app simply loads and stores contacts and is responsible for maintaining its own view. Changes are sent for changes made after the database was opened. KCalCore is based on the concept of loading a calendar (partially) into the client, modifying it there, then writing it back. Changes are also sent while the storage is open.

TODO:

=== Suppress Unnecessary Data Transfer ===

EDS currently sends all data when a view is requested, which is unnecessary when the client is only interested in change notifications. An extension to the EDS query language could optionally suppresses that sending of existing data when the view is opened, to be implemented only for the local contacts and calendar backends. This would allow easier integration with the QContact API.

The Fremantle EDS fork also had a “freezable” (static) capability for libebook, which should probably be investigated. See, for instance: http://maemo.org/api_refs/5.0/5.0-final/libebook/EBookView.html#e-book-view-set-freezable

One possibility for adding the flag is to (ab)use the existing query language with a match for special fields:
* in the client: query = e_book_query_orv(e_book_query_field_exists("X-EDS-QUERY-FLAG-SKIP-DATA-DUMP"), <real query>, NULL);
* in the server: "if (query is OR-Query and first clause is exists("X-EDS-QUERY-FLAG-SKIP-DATA-DUMP")) { skip_data_dump = TRUE; query = second clause; }

=== Return UIDs Only ===

The e_book_get_book_view() function takes a list of requested fields, to avoid returning unnecessary data, but this is apparently ignored for the local contacts backend. It would anyway require extra parsing and generation of smaller VCards, losing some possible advantages from delayed parsing of VCards.

However, the UID is already stored separately for use as the primary key of the BDB database, so it would be worthwhile to support that particular requested field. This would allow easier integration with the QContact API. It would also offer much better performance in cases where the client already has the data but just wants to discover what subset of that data meets a certain criteria.

Chris discovered a dedicated API for this in the Fremantle EDS fork. The new API call was accepted upstream and backported to gnome-2-32, so no further work is needed?

== Optional Parsing of ebook Data in Client ==

libebook provides different functionality:
# exchange data as vCard with EDS daemon
# parse items and wrap them in a C API

QtContacts replaces the second part. An obvious performance improvement is to only do the second part if the additional C APIs are really called. The following calls then transfer data without any additional parsing in libebook:
* e_book_get_contact()/asynchronous read/view + e_vcard_to_string()
* e_contact_new_from_vcard() + e_book_add_contact()/e_book_commit_contact()/asynchronous storing

Note that libecal (for iCalendar) can already do this, though libebook can't yet.

TODO:
# add delayed parsing to libebook, triggered by API call which needs parsed data

PROBLEM:
# If delayed parsing fails, how can error be reported?
# Should delayed parsing be done always (e_vcard_to_string())) or only if requested? How would that be configured by a libebook user?

== More Efficient Access to Meta Data for Change Tracking ==

This was discussed a while ago: [[http://www.mail-archive.com/evolution-hackers@gnome.org/msg03029.html
[Evolution-hackers] concurrent modifications of items in GUI and EDS database]]

Data synchronization only needs to know which items exist (list of local IDs) and which revision of each item is currently stored. Revisions can be identified with a string which changes for each modification. Restoring an older revision should (but doesn't have to) restore the revision string.

For calendar, UID+RECURRENCE-ID and LAST-MODIFIED can be used. For contacts, UID + REV.

By comparing a stored list against the current one, changes can be detected without relying on journals in the daemon or comparison of time stamps. Journals are hard to maintain (how many of them, how long?). Comparison of time stamps has problems when changes are allowed while a sync runs and assumes that system time is linear (which is not always true).

As an additional use case, local ID + revision string could be used to prevent overwriting stale data in the server, as in HTTP PUT eTag checks.

TODO:

The Maemo Fremantle port of EDS, which is of course already open source, apparently has some solution for this, according to Mathias Hasselman, so that should be investigated first.

However, this should probably be made possible by:

# Extending the EDS query language with a flag that limits the delivered data to just:
## UID and REV for libebook (REV is in VCard 3.0)
## UID+RECURRENCE-ID+LAST-MODIFIED, for libecal
# Implementing these queries for the local contact and calendar backends. The query would be rejected, with an error, for other backends.

== Atomic Updates ==

Later, implement atomic changes as discussed in the mail thread: [[http://www.mail-archive.com/evolution-hackers@gnome.org/msg03029.html

== Quick check for "data changed" ==

The libebook and libical APIs should offer a way to discover if any data whatsoever has changed. This would, for instance, help SyncEvolution to avoid unnecessary detailed checking. This could just check the modification dates of local storage files, such as the BDB .db file, or .ics file, as long as we do not use those files to store permanent caches of parsed data. This would be much quicker than listing items for the whole database and comparing their revisions strings, as is currently necessary.

This would require small API additions, to check that the opaque revision strings are unchanged, such as

gchar* e_book_get_revision(EBook *book)
gboolean e_book_check_revision(EBook *book , const gchar* revision)

and

gchar* e_cal_get_revision(ECal *ecal)
gboolean e_cal_check_revision(ECal ecal, const gchar revision)

The semantic would be this:
* If the revision string is empty or different, then the content of the database '''might''' have changed. A more detailed check is necessary to determine if it has really changed. This will be the case for non-local storage.
* If it is non-empty and the same as before, the nothing has changed. No further check will be necessary.

== Contacts: Store PHOTO Data as Plain Files ==

Photos should be transferred over D-Bus via a filepath to a local file rather than transferring the actual photo data over D-Bus. The VCard format already allows this option (See the PHOTO property). We must be careful to keep these local files in sync and to remove them when contacts are removed, and to restrict access to the files from other processes.

There should be utility code available to libebook users to convert between the different representations.

Goals:
# Apps should be able to create photo files without ever passing the data to libebook.
# External PHOTO file and corresponding contact must be kept in sync:
** If a contact is deleted, the photo also needs to be removed.
** If a photo file is created and then storing the contact fails, who removes the file?
# Access to photo data must be limited to processes which have the right permissions.

Proposal:
* For each ~/.local/share/evolution/foo calendar, store photos in <photo path>=~/.local/share/evolution/foo/photos, with same permissions.
* New photo files are created with a [http://en.wikipedia.org/wiki/Universally_unique_identifier UUID] as base name and suffix according to the file content.
* If a contact is deleted and has a PHOTO;VALUE=uri:file://<photo path>/*, delete that file.
* For apps which want to create the photo file directly:
** Apps get a file descriptor and the path from a new libebook API.
** They own the file until the EDS server acknowledges the successful storing of a contact with a matching PHOTO;VALUE=uri:file property. If that fails, the app must remove the file.
* Add new API calls to libebook which split out resp. include data inline.
** Must track ownership of file after splitting it out and before storing - might never get stored!

Open:
* Should there be automatic garbage collection of stale photos in case something went wrong and a photo wasn't properly deleted?
* Trust TYPE=JPEG/PNG/... or look into file content to determine type?

Architecture/planning/evolution-data-server

2011-04-30T18:48:13Z

Pohly: /* Contact Storage */

== Introduction ==

The architecture decision to make the transition from Nokia-supported components for contacts and calendar data (PIM) storage, email storage and transports, and sync back to the components used in MeeGo Netbook (Evolution Data Server and SyncEvolution) [http://lists.meego.com/pipermail/meego-dev/2011-March/481890.html was announced publicly] on March 7th. Planning the execution of that change is currently (end of March 2011) in progress.

This page gathers information about the PIM + mail storages and sync. Main author and point of contact is [mailto:patrick.ohly@intel.com Patrick Ohly]. It includes information contributed by various people, mentioned with email address below.

Information that has not been confirmed is marked with a question mark.

[[File:Qtcontacts-kcal-eds.png]]

== Calendar Storage ==

'''Maemo solution''': QtMobility/QtOrganizer (API) + KCalCore (MeeGo) + modifications + mKCal (sqlite storage) 
'''EDS proposal''': QtMobility/QtOrganizer (API) + KCalCore (KDE-compatible) + [[/KCal-EDS/]] + libecal/libical (client side) + EDS (server side, stored in iCalendar 2.0 text file) 
'''Used by''': calendar app ([mailto:sirisha.muppavarapu@intel.com Sirisha Muppavarapu]), clock app (originally [mailto:todd.e.brandt@intel.com Todd Brandt])

'''Advantages of mKCal''':
* partial loading of data from sqlite (not used by calendar app); EDS holds complete calendar in memory
* incremental changes to database; EDS must rewrite complete file
'''Disadvantages of mKCal (current implementation)''':
* only provides single "database changed" signal, forces apps to reload everything (not currently done in calendar app); EDS sends add/update/delete notifications to apps watching a calendar

Plan:
* use upstream KDE version of KCalCore (current MeeGo version has semantic differences in event->dtEnd()), with those changes that are necessary to run in MeeGo (embedded KDateTime, timed integration)
* write [[/KCal-EDS|storage which uses libecal/EDS]]
* [[/eds-improvements|EDS improvements]]

== Contact Storage ==

'''Maemo solution''': QtContacts (API) + QtContacts-Tracker (mapping to storage, searching) + Tracker (storage) + contactsd (updating presence information in Tracker) 
'''EDS proposal''': QtContacts (API) + [[/QtContacts storage plugin|QtContacts-EDS]] + libebook (client side) + EDS (server side, storage of vCards in Berkley DB); libfolks as replacement for contactsd 
'''Used by''': libseaside/meego-app-contacts/meego-handset-people/ContactPicker.qml ([mailto:connie.berardi@intel.com Connie Berardi] and [mailto:kaitlin.rupert@intel.com Kaitlin Rupert]), SMS and Messaging apps ([mailto:benjamin.t.drucker@intel.com Ben Drucker]), various parts of Tablet UX via QML binding, obexd for Phone Book Access Protocol (PBAP) plugin) 

'''Advantages of Tracker''':
* supports potential future use cases (combining data from different categories, partial reading/writing, fine-grained annotations on data origin)
* better searching
* scalability (?)
* read performance (?)

'''Disadvantages of Tracker''':
* data protection missing in both EDS and Tracker, but less obvious how to implement it in Tracker
* slow write performance in QtContacts-Tracker (?)

'''Plan''':
* write a QtContacts storage plugin ([[/QtContacts storage plugin|details on QtContacts-EDS]]),
* [[/eds-improvements|EDS improvements]]
* libfolks provides a QtContacts API (in addition to native APIs) and can use either Tracker or EDS directly as backends. Additional work will be needed to improve the EDS part and performance/memory usage.

'''Opens''':
* obexd has PBAP plugin for EDS, needs to be tested/improved/adapted (photo support, vCard 2.1/3.0); can't use QtContacts-EDS because obexd accesses Tracker directly
* [http://lists.meego.com/pipermail/meego-dev/2011-March/482065.html communication history], currently done with QSettings in dialer app - how will that be done in the future?

== Mail Storage and Transports ==

'''Maemo solution''': QtMobility/QtMessaging (API) + Qt Messaging Framework (QMF, actual implementation) 
'''EDS proposal''': QtMobility/QtMessaging (API) + QMF-compatible API (?) + Camel library (part of EDS, but not running in the daemon itself yet) 
'''Used by''': mail app ([mailto:carl.wong@intel.com Carl Wong]), SMS storage plugin ([mailto:benjamin.t.drucker@intel.com Ben Drucker])

'''Advantages of QMF''':
* already works as a stand-alone daemon

'''Plan A [[/email-design|(details)]]'''
* kudos to [mailto:srinivasa.ragavan.venkateswaran@intel.com Srinivasa (Srini) Venkateswaran] for this proposal
* write simplistic server which runs Camel
* replace QMF client library with one which accesses that server - ideally this library is at least QMF API source code compatible (=> adapting apps and QtMobility/QtMessaging requires recompilation, not rewriting)
* account setup UI

Some possible variations of plan A:
* rewrite mail app and QtMobility/QtMessaging to use Camel daemon via D-Bus
* QMF (source code) compatible replacement, used by mail app and Messaging (proposal above)
* rewrite mail app to use Messaging, rewrite Messaging to use Camel via D-Bus

'''Plan B''':
* keep QMF as mail infrastructure

== Data Synchronization ==
'''Maemo solution''': Buteo Sync Framework, Buteo SyncML, Buteo Sync Plugins, Buteo Media Transfer Protocol (MTP) 
'''Alternative''': SyncEvolution, Synthesis SyncML, Buteo Media Transfer Protocol 

'''Advantages of Buteo''':
* plugable sync engines, more sophisticated scheduling of time-based syncs
* Tablet Google Contact sync preserves properties not supported by Google

'''Disadvantages of Buteo''':
* incomplete, untested (in MeeGo)
* no support for incoming SyncML over OBEX/Bluetooth

'''Step 1''':
* keep Buteo Sync Framework
* replace SyncML engine for Google Contact sync in Tablet with SyncEvolution + Synthesis:
** The [http://meego.gitorious.org/meego-middleware/syncevolution/blobs/master/src/backends/buteo/ButeoBridge.cpp existing Buteo sync plugin] must also [https://bugs.meego.com/show_bug.cgi?id=15031 support Google Contacts]. No support for any other SyncML peer. This is the only SyncML peer which was tested with Buteo in MeeGo (done by the Intel Tablet team), so not supporting other SyncML peers in step 1 is not a regression.
** [https://bugs.meego.com/show_bug.cgi?id=15030 Preserving local extensions] when synchronizing with Google depends on [https://bugs.meego.com/show_bug.cgi?id=15029 hard-coding capabilities of that peer] and [https://bugs.meego.com/show_bug.cgi?id=15030 support for unknown properties].
** Google Contact sync might run in parallel with CalDAV sync. The SyncEvolution sync plugin must support that. Must [https://bugs.meego.com/show_bug.cgi?id=681 replace global variables].

'''Step 2''':
* rewrite QML settings backend to use SyncEvolution D-Bus API
* remove Buteo msyncd/framework, run Buteo MTP as part of syncevo-dbus-server or stand-alone

'''Further improvements to SyncEvolution/MTP''':
* code refactoring of libsynthesis to support non-SyncML sync scenarios and plain C code which needs data conversion (obexd plugin?)
* support push sync
* redesign daemon to run syncs in forked processes (security, responsiveness of D-Bus API)
* device-to-device sync over WLAN
* MTP over WLAN and Bluetooth

File:Qtcontacts-kcal-eds.png

2011-04-21T13:34:34Z

Pohly:

Architecture/planning/evolution-data-server

2011-04-21T13:32:15Z

Pohly: /* Introduction */

== Introduction ==

The architecture decision to make the transition from Nokia-supported components for contacts and calendar data (PIM) storage, email storage and transports, and sync back to the components used in MeeGo Netbook (Evolution Data Server and SyncEvolution) [http://lists.meego.com/pipermail/meego-dev/2011-March/481890.html was announced publicly] on March 7th. Planning the execution of that change is currently (end of March 2011) in progress.

This page gathers information about the PIM + mail storages and sync. Main author and point of contact is [mailto:patrick.ohly@intel.com Patrick Ohly]. It includes information contributed by various people, mentioned with email address below.

Information that has not been confirmed is marked with a question mark.

[[File:Qtcontacts-kcal-eds.png]]

== Calendar Storage ==

'''Maemo solution''': QtMobility/QtOrganizer (API) + KCalCore (MeeGo) + modifications + mKCal (sqlite storage) 
'''EDS proposal''': QtMobility/QtOrganizer (API) + KCalCore (KDE-compatible) + [[/KCal-EDS/]] + libecal/libical (client side) + EDS (server side, stored in iCalendar 2.0 text file) 
'''Used by''': calendar app ([mailto:sirisha.muppavarapu@intel.com Sirisha Muppavarapu]), clock app (originally [mailto:todd.e.brandt@intel.com Todd Brandt])

'''Advantages of mKCal''':
* partial loading of data from sqlite (not used by calendar app); EDS holds complete calendar in memory
* incremental changes to database; EDS must rewrite complete file
'''Disadvantages of mKCal (current implementation)''':
* only provides single "database changed" signal, forces apps to reload everything (not currently done in calendar app); EDS sends add/update/delete notifications to apps watching a calendar

Plan:
* use upstream KDE version of KCalCore (current MeeGo version has semantic differences in event->dtEnd()), with those changes that are necessary to run in MeeGo (embedded KDateTime, timed integration)
* write [[/KCal-EDS|storage which uses libecal/EDS]]
* [[/eds-improvements|EDS improvements]]

== Contact Storage ==

'''Maemo solution''': QtContacts (API) + QtContacts-Tracker (glue code) + Tracker (storage) + contactsd (updating presence information in Tracker) 
'''EDS proposal''': QtContacts (API) + [[/QtContacts storage plugin|QtContacts-EDS]] + libebook (client side) + EDS (server side, storage of vCards in Berkley DB); libfolks as replacement for contactsd 
'''Used by''': libseaside/meego-app-contacts/meego-handset-people/ContactPicker.qml ([mailto:connie.berardi@intel.com Connie Berardi] and [mailto:kaitlin.rupert@intel.com]), SMS and Messaging apps ([mailto:benjamin.t.drucker@intel.com Ben Drucker]), various parts of Tablet UX via QML binding, obexd for Phone Book Access Protocol (PBAP) plugin) 

'''Advantages of Tracker''':
* supports potential future use cases (combining data from different categories, partial reading/writing, fine-grained annotations on data origin)
* better searching
* scalability (?)
* read performance (?)

'''Disadvantages of Tracker''':
* data protection missing in both EDS and Tracker, but less obvious how to implement it in Tracker
* slow write performance in QtContacts-Tracker (?)

'''Plan''':
* write a QtContacts storage plugin ([[/QtContacts storage plugin|details on QtContacts-EDS]]),
* [[/eds-improvements|EDS improvements]]
* libfolks provides a QtContacts API (in addition to native APIs) and can use either Tracker or EDS directly as backends. Additional work will be needed to improve the EDS part and performance/memory usage.

'''Opens''':
* obexd has PBAP plugin for EDS, needs to be tested/improved/adapted (photo support, vCard 2.1/3.0); can't use QtContacts-EDS because obexd accesses Tracker directly
* [http://lists.meego.com/pipermail/meego-dev/2011-March/482065.html communication history], currently done with QSettings in dialer app - how will that be done in the future?

== Mail Storage and Transports ==

'''Maemo solution''': QtMobility/QtMessaging (API) + Qt Messaging Framework (QMF, actual implementation) 
'''EDS proposal''': QtMobility/QtMessaging (API) + QMF-compatible API (?) + Camel library (part of EDS, but not running in the daemon itself yet) 
'''Used by''': mail app ([mailto:carl.wong@intel.com Carl Wong]), SMS storage plugin ([mailto:benjamin.t.drucker@intel.com Ben Drucker])

'''Advantages of QMF''':
* already works as a stand-alone daemon

'''Plan A [[/email-design|(details)]]'''
* kudos to [mailto:srinivasa.ragavan.venkateswaran@intel.com Srinivasa (Srini) Venkateswaran] for this proposal
* write simplistic server which runs Camel
* replace QMF client library with one which accesses that server - ideally this library is at least QMF API source code compatible (=> adapting apps and QtMobility/QtMessaging requires recompilation, not rewriting)
* account setup UI

Some possible variations of plan A:
* rewrite mail app and QtMobility/QtMessaging to use Camel daemon via D-Bus
* QMF (source code) compatible replacement, used by mail app and Messaging (proposal above)
* rewrite mail app to use Messaging, rewrite Messaging to use Camel via D-Bus

'''Plan B''':
* keep QMF as mail infrastructure

== Data Synchronization ==
'''Maemo solution''': Buteo Sync Framework, Buteo SyncML, Buteo Sync Plugins, Buteo Media Transfer Protocol (MTP) 
'''Alternative''': SyncEvolution, Synthesis SyncML, Buteo Media Transfer Protocol 

'''Advantages of Buteo''':
* plugable sync engines, more sophisticated scheduling of time-based syncs
* Tablet Google Contact sync preserves properties not supported by Google

'''Disadvantages of Buteo''':
* incomplete, untested (in MeeGo)
* no support for incoming SyncML over OBEX/Bluetooth

'''Step 1''':
* keep Buteo Sync Framework
* replace SyncML engine for Google Contact sync in Tablet with SyncEvolution + Synthesis:
** The [http://meego.gitorious.org/meego-middleware/syncevolution/blobs/master/src/backends/buteo/ButeoBridge.cpp existing Buteo sync plugin] must also [https://bugs.meego.com/show_bug.cgi?id=15031 support Google Contacts]. No support for any other SyncML peer. This is the only SyncML peer which was tested with Buteo in MeeGo (done by the Intel Tablet team), so not supporting other SyncML peers in step 1 is not a regression.
** [https://bugs.meego.com/show_bug.cgi?id=15030 Preserving local extensions] when synchronizing with Google depends on [https://bugs.meego.com/show_bug.cgi?id=15029 hard-coding capabilities of that peer] and [https://bugs.meego.com/show_bug.cgi?id=15030 support for unknown properties].
** Google Contact sync might run in parallel with CalDAV sync. The SyncEvolution sync plugin must support that. Must [https://bugs.meego.com/show_bug.cgi?id=681 replace global variables].

'''Step 2''':
* rewrite QML settings backend to use SyncEvolution D-Bus API
* remove Buteo msyncd/framework, run Buteo MTP as part of syncevo-dbus-server or stand-alone

'''Further improvements to SyncEvolution/MTP''':
* code refactoring of libsynthesis to support non-SyncML sync scenarios and plain C code which needs data conversion (obexd plugin?)
* support push sync
* redesign daemon to run syncs in forked processes (security, responsiveness of D-Bus API)
* device-to-device sync over WLAN
* MTP over WLAN and Bluetooth

Architecture/planning/evolution-data-server

2011-04-21T13:29:09Z

Pohly: /* Introduction */

== Introduction ==

The architecture decision to make the transition from Nokia-supported components for contacts and calendar data (PIM) storage, email storage and transports, and sync back to the components used in MeeGo Netbook (Evolution Data Server and SyncEvolution) [http://lists.meego.com/pipermail/meego-dev/2011-March/481890.html was announced publicly] on March 7th. Planning the execution of that change is currently (end of March 2011) in progress.

This page gathers information about the PIM + mail storages and sync. Main author and point of contact is [mailto:patrick.ohly@intel.com Patrick Ohly]. It includes information contributed by various people, mentioned with email address below.

Information that has not been confirmed is marked with a question mark.

[[File:qtcontacts-kcal-eds.png]]

== Calendar Storage ==

'''Maemo solution''': QtMobility/QtOrganizer (API) + KCalCore (MeeGo) + modifications + mKCal (sqlite storage) 
'''EDS proposal''': QtMobility/QtOrganizer (API) + KCalCore (KDE-compatible) + [[/KCal-EDS/]] + libecal/libical (client side) + EDS (server side, stored in iCalendar 2.0 text file) 
'''Used by''': calendar app ([mailto:sirisha.muppavarapu@intel.com Sirisha Muppavarapu]), clock app (originally [mailto:todd.e.brandt@intel.com Todd Brandt])

'''Advantages of mKCal''':
* partial loading of data from sqlite (not used by calendar app); EDS holds complete calendar in memory
* incremental changes to database; EDS must rewrite complete file
'''Disadvantages of mKCal (current implementation)''':
* only provides single "database changed" signal, forces apps to reload everything (not currently done in calendar app); EDS sends add/update/delete notifications to apps watching a calendar

Plan:
* use upstream KDE version of KCalCore (current MeeGo version has semantic differences in event->dtEnd()), with those changes that are necessary to run in MeeGo (embedded KDateTime, timed integration)
* write [[/KCal-EDS|storage which uses libecal/EDS]]
* [[/eds-improvements|EDS improvements]]

== Contact Storage ==

'''Maemo solution''': QtContacts (API) + QtContacts-Tracker (glue code) + Tracker (storage) + contactsd (updating presence information in Tracker) 
'''EDS proposal''': QtContacts (API) + [[/QtContacts storage plugin|QtContacts-EDS]] + libebook (client side) + EDS (server side, storage of vCards in Berkley DB); libfolks as replacement for contactsd 
'''Used by''': libseaside/meego-app-contacts/meego-handset-people/ContactPicker.qml ([mailto:connie.berardi@intel.com Connie Berardi] and [mailto:kaitlin.rupert@intel.com]), SMS and Messaging apps ([mailto:benjamin.t.drucker@intel.com Ben Drucker]), various parts of Tablet UX via QML binding, obexd for Phone Book Access Protocol (PBAP) plugin) 

'''Advantages of Tracker''':
* supports potential future use cases (combining data from different categories, partial reading/writing, fine-grained annotations on data origin)
* better searching
* scalability (?)
* read performance (?)

'''Disadvantages of Tracker''':
* data protection missing in both EDS and Tracker, but less obvious how to implement it in Tracker
* slow write performance in QtContacts-Tracker (?)

'''Plan''':
* write a QtContacts storage plugin ([[/QtContacts storage plugin|details on QtContacts-EDS]]),
* [[/eds-improvements|EDS improvements]]
* libfolks provides a QtContacts API (in addition to native APIs) and can use either Tracker or EDS directly as backends. Additional work will be needed to improve the EDS part and performance/memory usage.

'''Opens''':
* obexd has PBAP plugin for EDS, needs to be tested/improved/adapted (photo support, vCard 2.1/3.0); can't use QtContacts-EDS because obexd accesses Tracker directly
* [http://lists.meego.com/pipermail/meego-dev/2011-March/482065.html communication history], currently done with QSettings in dialer app - how will that be done in the future?

== Mail Storage and Transports ==

'''Maemo solution''': QtMobility/QtMessaging (API) + Qt Messaging Framework (QMF, actual implementation) 
'''EDS proposal''': QtMobility/QtMessaging (API) + QMF-compatible API (?) + Camel library (part of EDS, but not running in the daemon itself yet) 
'''Used by''': mail app ([mailto:carl.wong@intel.com Carl Wong]), SMS storage plugin ([mailto:benjamin.t.drucker@intel.com Ben Drucker])

'''Advantages of QMF''':
* already works as a stand-alone daemon

'''Plan A [[/email-design|(details)]]'''
* kudos to [mailto:srinivasa.ragavan.venkateswaran@intel.com Srinivasa (Srini) Venkateswaran] for this proposal
* write simplistic server which runs Camel
* replace QMF client library with one which accesses that server - ideally this library is at least QMF API source code compatible (=> adapting apps and QtMobility/QtMessaging requires recompilation, not rewriting)
* account setup UI

Some possible variations of plan A:
* rewrite mail app and QtMobility/QtMessaging to use Camel daemon via D-Bus
* QMF (source code) compatible replacement, used by mail app and Messaging (proposal above)
* rewrite mail app to use Messaging, rewrite Messaging to use Camel via D-Bus

'''Plan B''':
* keep QMF as mail infrastructure

== Data Synchronization ==
'''Maemo solution''': Buteo Sync Framework, Buteo SyncML, Buteo Sync Plugins, Buteo Media Transfer Protocol (MTP) 
'''Alternative''': SyncEvolution, Synthesis SyncML, Buteo Media Transfer Protocol 

'''Advantages of Buteo''':
* plugable sync engines, more sophisticated scheduling of time-based syncs
* Tablet Google Contact sync preserves properties not supported by Google

'''Disadvantages of Buteo''':
* incomplete, untested (in MeeGo)
* no support for incoming SyncML over OBEX/Bluetooth

'''Step 1''':
* keep Buteo Sync Framework
* replace SyncML engine for Google Contact sync in Tablet with SyncEvolution + Synthesis:
** The [http://meego.gitorious.org/meego-middleware/syncevolution/blobs/master/src/backends/buteo/ButeoBridge.cpp existing Buteo sync plugin] must also [https://bugs.meego.com/show_bug.cgi?id=15031 support Google Contacts]. No support for any other SyncML peer. This is the only SyncML peer which was tested with Buteo in MeeGo (done by the Intel Tablet team), so not supporting other SyncML peers in step 1 is not a regression.
** [https://bugs.meego.com/show_bug.cgi?id=15030 Preserving local extensions] when synchronizing with Google depends on [https://bugs.meego.com/show_bug.cgi?id=15029 hard-coding capabilities of that peer] and [https://bugs.meego.com/show_bug.cgi?id=15030 support for unknown properties].
** Google Contact sync might run in parallel with CalDAV sync. The SyncEvolution sync plugin must support that. Must [https://bugs.meego.com/show_bug.cgi?id=681 replace global variables].

'''Step 2''':
* rewrite QML settings backend to use SyncEvolution D-Bus API
* remove Buteo msyncd/framework, run Buteo MTP as part of syncevo-dbus-server or stand-alone

'''Further improvements to SyncEvolution/MTP''':
* code refactoring of libsynthesis to support non-SyncML sync scenarios and plain C code which needs data conversion (obexd plugin?)
* support push sync
* redesign daemon to run syncs in forked processes (security, responsiveness of D-Bus API)
* device-to-device sync over WLAN
* MTP over WLAN and Bluetooth

File:Qtcontact-kcal-eds.png

2011-04-21T13:27:15Z

Pohly:

Architecture/planning/evolution-data-server

2011-04-13T07:04:39Z

Pohly: /* Mail Storage and Transports */

== Introduction ==

The architecture decision to make the transition from Nokia-supported components for contacts and calendar data (PIM) storage, email storage and transports, and sync back to the components used in MeeGo Netbook (Evolution Data Server and SyncEvolution) [http://lists.meego.com/pipermail/meego-dev/2011-March/481890.html was announced publicly] on March 7th. Planning the execution of that change is currently (end of March 2011) in progress.

This page gathers information about the PIM + mail storages and sync. Main author and point of contact is [mailto:patrick.ohly@intel.com Patrick Ohly]. It includes information contributed by various people, mentioned with email address below.

Information that has not been confirmed is marked with a question mark.

== Calendar Storage ==

'''Maemo solution''': QtMobility/QtOrganizer (API) + KCalCore (MeeGo) + modifications + mKCal (sqlite storage) 
'''EDS proposal''': QtMobility/QtOrganizer (API) + KCalCore (KDE-compatible) + [[/KCal-EDS/]] + libecal/libical (client side) + EDS (server side, stored in iCalendar 2.0 text file) 
'''Used by''': calendar app ([mailto:sirisha.muppavarapu@intel.com Sirisha Muppavarapu]), clock app (originally [mailto:todd.e.brandt@intel.com Todd Brandt])

'''Advantages of mKCal''':
* partial loading of data from sqlite (not used by calendar app); EDS holds complete calendar in memory
* incremental changes to database; EDS must rewrite complete file
'''Disadvantages of mKCal (current implementation)''':
* only provides single "database changed" signal, forces apps to reload everything (not currently done in calendar app); EDS sends add/update/delete notifications to apps watching a calendar

Plan:
* use upstream KDE version of KCalCore (current MeeGo version has semantic differences in event->dtEnd()), with those changes that are necessary to run in MeeGo (embedded KDateTime, timed integration)
* write [[/KCal-EDS|storage which uses libecal/EDS]]
* [[/eds-improvements|EDS improvements]]

== Contact Storage ==

'''Maemo solution''': QtContacts (API) + QtContacts-Tracker (glue code) + Tracker (storage) + contactsd (updating presence information in Tracker) 
'''EDS proposal''': QtContacts (API) + [[/QtContacts storage plugin|QtContacts-EDS]] + libebook (client side) + EDS (server side, storage of vCards in Berkley DB); libfolks as replacement for contactsd 
'''Used by''': libseaside/meego-app-contacts/meego-handset-people/ContactPicker.qml ([mailto:connie.berardi@intel.com Connie Berardi] and [mailto:kaitlin.rupert@intel.com]), SMS and Messaging apps ([mailto:benjamin.t.drucker@intel.com Ben Drucker]), various parts of Tablet UX via QML binding, obexd for Phone Book Access Protocol (PBAP) plugin) 

'''Advantages of Tracker''':
* supports potential future use cases (combining data from different categories, partial reading/writing, fine-grained annotations on data origin)
* better searching
* scalability (?)
* read performance (?)

'''Disadvantages of Tracker''':
* data protection missing in both EDS and Tracker, but less obvious how to implement it in Tracker
* slow write performance in QtContacts-Tracker (?)

'''Plan''':
* write a QtContacts storage plugin ([[/QtContacts storage plugin|details on QtContacts-EDS]]),
* [[/eds-improvements|EDS improvements]]
* libfolks provides a QtContacts API (in addition to native APIs) and can use either Tracker or EDS directly as backends. Additional work will be needed to improve the EDS part and performance/memory usage.

'''Opens''':
* obexd has PBAP plugin for EDS, needs to be tested/improved/adapted (photo support, vCard 2.1/3.0); can't use QtContacts-EDS because obexd accesses Tracker directly
* [http://lists.meego.com/pipermail/meego-dev/2011-March/482065.html communication history], currently done with QSettings in dialer app - how will that be done in the future?

== Mail Storage and Transports ==

'''Maemo solution''': QtMobility/QtMessaging (API) + Qt Messaging Framework (QMF, actual implementation) 
'''EDS proposal''': QtMobility/QtMessaging (API) + QMF-compatible API (?) + Camel library (part of EDS, but not running in the daemon itself yet) 
'''Used by''': mail app ([mailto:carl.wong@intel.com Carl Wong]), SMS storage plugin ([mailto:benjamin.t.drucker@intel.com Ben Drucker])

'''Advantages of QMF''':
* already works as a stand-alone daemon

'''Plan A [[/email-design|(details)]]'''
* kudos to [mailto:srinivasa.ragavan.venkateswaran@intel.com Srinivasa (Srini) Venkateswaran] for this proposal
* write simplistic server which runs Camel
* replace QMF client library with one which accesses that server - ideally this library is at least QMF API source code compatible (=> adapting apps and QtMobility/QtMessaging requires recompilation, not rewriting)
* account setup UI

Some possible variations of plan A:
* rewrite mail app and QtMobility/QtMessaging to use Camel daemon via D-Bus
* QMF (source code) compatible replacement, used by mail app and Messaging (proposal above)
* rewrite mail app to use Messaging, rewrite Messaging to use Camel via D-Bus

'''Plan B''':
* keep QMF as mail infrastructure

== Data Synchronization ==
'''Maemo solution''': Buteo Sync Framework, Buteo SyncML, Buteo Sync Plugins, Buteo Media Transfer Protocol (MTP) 
'''Alternative''': SyncEvolution, Synthesis SyncML, Buteo Media Transfer Protocol 

'''Advantages of Buteo''':
* plugable sync engines, more sophisticated scheduling of time-based syncs
* Tablet Google Contact sync preserves properties not supported by Google

'''Disadvantages of Buteo''':
* incomplete, untested (in MeeGo)
* no support for incoming SyncML over OBEX/Bluetooth

'''Step 1''':
* keep Buteo Sync Framework
* replace SyncML engine for Google Contact sync in Tablet with SyncEvolution + Synthesis:
** The [http://meego.gitorious.org/meego-middleware/syncevolution/blobs/master/src/backends/buteo/ButeoBridge.cpp existing Buteo sync plugin] must also [https://bugs.meego.com/show_bug.cgi?id=15031 support Google Contacts]. No support for any other SyncML peer. This is the only SyncML peer which was tested with Buteo in MeeGo (done by the Intel Tablet team), so not supporting other SyncML peers in step 1 is not a regression.
** [https://bugs.meego.com/show_bug.cgi?id=15030 Preserving local extensions] when synchronizing with Google depends on [https://bugs.meego.com/show_bug.cgi?id=15029 hard-coding capabilities of that peer] and [https://bugs.meego.com/show_bug.cgi?id=15030 support for unknown properties].
** Google Contact sync might run in parallel with CalDAV sync. The SyncEvolution sync plugin must support that. Must [https://bugs.meego.com/show_bug.cgi?id=681 replace global variables].

'''Step 2''':
* rewrite QML settings backend to use SyncEvolution D-Bus API
* remove Buteo msyncd/framework, run Buteo MTP as part of syncevo-dbus-server or stand-alone

'''Further improvements to SyncEvolution/MTP''':
* code refactoring of libsynthesis to support non-SyncML sync scenarios and plain C code which needs data conversion (obexd plugin?)
* support push sync
* redesign daemon to run syncs in forked processes (security, responsiveness of D-Bus API)
* device-to-device sync over WLAN
* MTP over WLAN and Bluetooth

Architecture/planning/evolution-data-server

2011-04-06T10:56:53Z

Pohly: /* Calendar Storage */

== Introduction ==

The architecture decision to make the transition from Nokia-supported components for contacts and calendar data (PIM) storage, email storage and transports, and sync back to the components used in MeeGo Netbook (Evolution Data Server and SyncEvolution) [http://lists.meego.com/pipermail/meego-dev/2011-March/481890.html was announced publicly] on March 7th. Planning the execution of that change is currently (end of March 2011) in progress.

This page gathers information about the PIM + mail storages and sync. Main author and point of contact is [mailto:patrick.ohly@intel.com Patrick Ohly]. It includes information contributed by various people, mentioned with email address below.

Information that has not been confirmed is marked with a question mark.

== Calendar Storage ==

'''Maemo solution''': QtMobility/QtOrganizer (API) + KCalCore (MeeGo) + modifications + mKCal (sqlite storage) 
'''EDS proposal''': QtMobility/QtOrganizer (API) + KCalCore (KDE-compatible) + [[/KCal-EDS|KCal-EDS]] + libecal/libical (client side) + EDS (server side, stored in iCalendar 2.0 text file) 
'''Used by''': calendar app ([mailto:sirisha.muppavarapu@intel.com Sirisha Muppavarapu]), clock app (originally [mailto:todd.e.brandt@intel.com Todd Brandt])

'''Advantages of mKCal''':
* partial loading of data from sqlite (not used by calendar app); EDS holds complete calendar in memory
* incremental changes to database; EDS must rewrite complete file
'''Disadvantages of mKCal (current implementation)''':
* only provides single "database changed" signal, forces apps to reload everything (not currently done in calendar app); EDS sends add/update/delete notifications to apps watching a calendar

Plan:
* use upstream KDE version of KCalCore (current MeeGo version has semantic differences in event->dtEnd()), with those changes that are necessary to run in MeeGo (embedded KDateTime, timed integration)
* write [[/KCal-EDS|storage which uses libecal/EDS]]
* [[/eds-improvements|EDS improvements]]

== Contact Storage ==

'''Maemo solution''': QtContacts (API) + QtContacts-Tracker (glue code) + Tracker (storage) + contactsd (updating presence information in Tracker) 
'''EDS proposal''': QtContacts (API) + [[/QtContacts storage plugin|QtContacts-EDS]] + libebook (client side) + EDS (server side, storage of vCards in Berkley DB); libfolks as replacement for contactsd 
'''Used by''': libseaside/meego-app-contacts/meego-handset-people/ContactPicker.qml ([mailto:connie.berardi@intel.com Connie Berardi] and [mailto:kaitlin.rupert@intel.com]), SMS and Messaging apps ([mailto:benjamin.t.drucker@intel.com Ben Drucker]), various parts of Tablet UX via QML binding, obexd for Phone Book Access Protocol (PBAP) plugin) 

'''Advantages of Tracker''':
* supports potential future use cases (combining data from different categories, partial reading/writing, fine-grained annotations on data origin)
* better searching
* scalability (?)
* read performance (?)

'''Disadvantages of Tracker''':
* data protection missing in both EDS and Tracker, but less obvious how to implement it in Tracker
* slow write performance in QtContacts-Tracker (?)

'''Plan''':
* write a QtContacts storage plugin ([[/QtContacts storage plugin|details on QtContacts-EDS]]),
* [[/eds-improvements|EDS improvements]]
* libfolks provides a QtContacts API (in addition to native APIs) and can use either Tracker or EDS directly as backends. Additional work will be needed to improve the EDS part and performance/memory usage.

'''Opens''':
* obexd has PBAP plugin for EDS, needs to be tested/improved/adapted (photo support, vCard 2.1/3.0); can't use QtContacts-EDS because obexd accesses Tracker directly
* [http://lists.meego.com/pipermail/meego-dev/2011-March/482065.html communication history], currently done with QSettings in dialer app - how will that be done in the future?

== Mail Storage and Transports ==

'''Maemo solution''': QtMobility/QtMessaging (API) + Qt Messaging Framework (QMF, actual implementation) 
'''EDS proposal''': QtMobility/QtMessaging (API) + QMF-compatible API (?) + Camel library (part of EDS, but not running in the daemon itself yet) 
'''Used by''': mail app ([mailto:carl.wong@intel.com Carl Wong]), SMS storage plugin ([mailto:benjamin.t.drucker@intel.com Ben Drucker])

'''Advantages of QMF''':
* already works as a stand-alone daemon

'''Plan A [[/QMF client lib substitution|(details)]]'''
* kudos to [mailto:srinivasa.ragavan.venkateswaran@intel.com Srinivasa (Srini) Venkateswaran] for this proposal
* write simplistic server which runs Camel
* replace QMF client library with one which accesses that server - ideally this library is at least QMF API source code compatible (=> adapting apps and QtMobility/QtMessaging requires recompilation, not rewriting)
* account setup UI

Some possible variations of plan A:
* rewrite mail app and QtMobility/QtMessaging to use Camel daemon via D-Bus
* QMF (source code) compatible replacement, used by mail app and Messaging (proposal above)
* rewrite mail app to use Messaging, rewrite Messaging to use Camel via D-Bus

'''Plan B''':
* keep QMF as mail infrastructure

== Data Synchronization ==
'''Maemo solution''': Buteo Sync Framework, Buteo SyncML, Buteo Sync Plugins, Buteo Media Transfer Protocol (MTP) 
'''Alternative''': SyncEvolution, Synthesis SyncML, Buteo Media Transfer Protocol 

'''Advantages of Buteo''':
* plugable sync engines, more sophisticated scheduling of time-based syncs
* Tablet Google Contact sync preserves properties not supported by Google

'''Disadvantages of Buteo''':
* incomplete, untested (in MeeGo)
* no support for incoming SyncML over OBEX/Bluetooth

'''Step 1''':
* keep Buteo Sync Framework
* replace SyncML engine for Google Contact sync in Tablet with SyncEvolution + Synthesis:
** The [http://meego.gitorious.org/meego-middleware/syncevolution/blobs/master/src/backends/buteo/ButeoBridge.cpp existing Buteo sync plugin] must also [https://bugs.meego.com/show_bug.cgi?id=15031 support Google Contacts]. No support for any other SyncML peer. This is the only SyncML peer which was tested with Buteo in MeeGo (done by the Intel Tablet team), so not supporting other SyncML peers in step 1 is not a regression.
** [https://bugs.meego.com/show_bug.cgi?id=15030 Preserving local extensions] when synchronizing with Google depends on [https://bugs.meego.com/show_bug.cgi?id=15029 hard-coding capabilities of that peer] and [https://bugs.meego.com/show_bug.cgi?id=15030 support for unknown properties].
** Google Contact sync might run in parallel with CalDAV sync. The SyncEvolution sync plugin must support that. Must [https://bugs.meego.com/show_bug.cgi?id=681 replace global variables].

'''Step 2''':
* rewrite QML settings backend to use SyncEvolution D-Bus API
* remove Buteo msyncd/framework, run Buteo MTP as part of syncevo-dbus-server or stand-alone

'''Further improvements to SyncEvolution/MTP''':
* code refactoring of libsynthesis to support non-SyncML sync scenarios and plain C code which needs data conversion (obexd plugin?)
* support push sync
* redesign daemon to run syncs in forked processes (security, responsiveness of D-Bus API)
* device-to-device sync over WLAN
* MTP over WLAN and Bluetooth

Architecture/planning/evolution-data-server

2011-04-06T10:50:44Z

Pohly: /* Calendar Storage */

== Introduction ==

The architecture decision to make the transition from Nokia-supported components for contacts and calendar data (PIM) storage, email storage and transports, and sync back to the components used in MeeGo Netbook (Evolution Data Server and SyncEvolution) [http://lists.meego.com/pipermail/meego-dev/2011-March/481890.html was announced publicly] on March 7th. Planning the execution of that change is currently (end of March 2011) in progress.

This page gathers information about the PIM + mail storages and sync. Main author and point of contact is [mailto:patrick.ohly@intel.com Patrick Ohly]. It includes information contributed by various people, mentioned with email address below.

Information that has not been confirmed is marked with a question mark.

== Calendar Storage ==

'''Maemo solution''': QtMobility/QtOrganizer (API) + KCalCore (KDE) + modifications + mKCal (sqlite storage) 
'''EDS proposal''': QtMobility/QtOrganizer (API) + [[/KCal-EDS|KCal-EDS]] + libecal/libical (client side) + EDS (server side, stored in iCalendar 2.0 text file) 
'''Used by''': calendar app ([mailto:sirisha.muppavarapu@intel.com Sirisha Muppavarapu]), clock app (originally [mailto:todd.e.brandt@intel.com Todd Brandt])

'''Advantages of mKCal''':
* partial loading of data from sqlite (not used by calendar app); EDS holds complete calendar in memory
* incremental changes to database; EDS must rewrite complete file
'''Disadvantages of mKCal (current implementation)''':
* only provides single "database changed" signal, forces apps to reload everything (not currently done in calendar app); EDS sends add/update/delete notifications to apps watching a calendar

Plan:
* use upstream KDE version of KCalCore (current MeeGo version has semantic differences in event->dtEnd())
* write [[/KCal-EDS|storage which uses libecal/EDS]]
* [[/eds-improvements|EDS improvements]]

== Contact Storage ==

'''Maemo solution''': QtContacts (API) + QtContacts-Tracker (glue code) + Tracker (storage) + contactsd (updating presence information in Tracker) 
'''EDS proposal''': QtContacts (API) + [[/QtContacts storage plugin|QtContacts-EDS]] + libebook (client side) + EDS (server side, storage of vCards in Berkley DB); libfolks as replacement for contactsd 
'''Used by''': libseaside/meego-app-contacts/meego-handset-people/ContactPicker.qml ([mailto:connie.berardi@intel.com Connie Berardi] and [mailto:kaitlin.rupert@intel.com]), SMS and Messaging apps ([mailto:benjamin.t.drucker@intel.com Ben Drucker]), various parts of Tablet UX via QML binding, obexd for Phone Book Access Protocol (PBAP) plugin) 

'''Advantages of Tracker''':
* supports potential future use cases (combining data from different categories, partial reading/writing, fine-grained annotations on data origin)
* better searching
* scalability (?)
* read performance (?)

'''Disadvantages of Tracker''':
* data protection missing in both EDS and Tracker, but less obvious how to implement it in Tracker
* slow write performance in QtContacts-Tracker (?)

'''Plan''':
* write a QtContacts storage plugin ([[/QtContacts storage plugin|details on QtContacts-EDS]]),
* [[/eds-improvements|EDS improvements]]
* libfolks provides a QtContacts API (in addition to native APIs) and can use either Tracker or EDS directly as backends. Additional work will be needed to improve the EDS part and performance/memory usage.

'''Opens''':
* obexd has PBAP plugin for EDS, needs to be tested/improved/adapted (photo support, vCard 2.1/3.0); can't use QtContacts-EDS because obexd accesses Tracker directly
* [http://lists.meego.com/pipermail/meego-dev/2011-March/482065.html communication history], currently done with QSettings in dialer app - how will that be done in the future?

== Mail Storage and Transports ==

'''Maemo solution''': QtMobility/QtMessaging (API) + Qt Messaging Framework (QMF, actual implementation) 
'''EDS proposal''': QtMobility/QtMessaging (API) + QMF-compatible API (?) + Camel library (part of EDS, but not running in the daemon itself yet) 
'''Used by''': mail app ([mailto:carl.wong@intel.com Carl Wong]), SMS storage plugin ([mailto:benjamin.t.drucker@intel.com Ben Drucker])

'''Advantages of QMF''':
* already works as a stand-alone daemon

'''Plan A [[/QMF client lib substitution|(details)]]'''
* kudos to [mailto:srinivasa.ragavan.venkateswaran@intel.com Srinivasa (Srini) Venkateswaran] for this proposal
* write simplistic server which runs Camel
* replace QMF client library with one which accesses that server - ideally this library is at least QMF API source code compatible (=> adapting apps and QtMobility/QtMessaging requires recompilation, not rewriting)
* account setup UI

Some possible variations of plan A:
* rewrite mail app and QtMobility/QtMessaging to use Camel daemon via D-Bus
* QMF (source code) compatible replacement, used by mail app and Messaging (proposal above)
* rewrite mail app to use Messaging, rewrite Messaging to use Camel via D-Bus

'''Plan B''':
* keep QMF as mail infrastructure

== Data Synchronization ==
'''Maemo solution''': Buteo Sync Framework, Buteo SyncML, Buteo Sync Plugins, Buteo Media Transfer Protocol (MTP) 
'''Alternative''': SyncEvolution, Synthesis SyncML, Buteo Media Transfer Protocol 

'''Advantages of Buteo''':
* plugable sync engines, more sophisticated scheduling of time-based syncs
* Tablet Google Contact sync preserves properties not supported by Google

'''Disadvantages of Buteo''':
* incomplete, untested (in MeeGo)
* no support for incoming SyncML over OBEX/Bluetooth

'''Step 1''':
* keep Buteo Sync Framework
* replace SyncML engine for Google Contact sync in Tablet with SyncEvolution + Synthesis:
** The [http://meego.gitorious.org/meego-middleware/syncevolution/blobs/master/src/backends/buteo/ButeoBridge.cpp existing Buteo sync plugin] must also [https://bugs.meego.com/show_bug.cgi?id=15031 support Google Contacts]. No support for any other SyncML peer. This is the only SyncML peer which was tested with Buteo in MeeGo (done by the Intel Tablet team), so not supporting other SyncML peers in step 1 is not a regression.
** [https://bugs.meego.com/show_bug.cgi?id=15030 Preserving local extensions] when synchronizing with Google depends on [https://bugs.meego.com/show_bug.cgi?id=15029 hard-coding capabilities of that peer] and [https://bugs.meego.com/show_bug.cgi?id=15030 support for unknown properties].
** Google Contact sync might run in parallel with CalDAV sync. The SyncEvolution sync plugin must support that. Must [https://bugs.meego.com/show_bug.cgi?id=681 replace global variables].

'''Step 2''':
* rewrite QML settings backend to use SyncEvolution D-Bus API
* remove Buteo msyncd/framework, run Buteo MTP as part of syncevo-dbus-server or stand-alone

'''Further improvements to SyncEvolution/MTP''':
* code refactoring of libsynthesis to support non-SyncML sync scenarios and plain C code which needs data conversion (obexd plugin?)
* support push sync
* redesign daemon to run syncs in forked processes (security, responsiveness of D-Bus API)
* device-to-device sync over WLAN
* MTP over WLAN and Bluetooth

Architecture/planning/evolution-data-server

2011-04-06T10:49:21Z

Pohly: /* Contact Storage */

== Introduction ==

The architecture decision to make the transition from Nokia-supported components for contacts and calendar data (PIM) storage, email storage and transports, and sync back to the components used in MeeGo Netbook (Evolution Data Server and SyncEvolution) [http://lists.meego.com/pipermail/meego-dev/2011-March/481890.html was announced publicly] on March 7th. Planning the execution of that change is currently (end of March 2011) in progress.

This page gathers information about the PIM + mail storages and sync. Main author and point of contact is [mailto:patrick.ohly@intel.com Patrick Ohly]. It includes information contributed by various people, mentioned with email address below.

Information that has not been confirmed is marked with a question mark.

== Calendar Storage ==

'''Maemo solution''': QtMobility/QtOrganizer (API) + KCalCore (KDE) + modifications + mKCal (sqlite storage) 
'''EDS proposal''': QtMobility/QtOrganizer (API) + [[/KCalCore-EDS]] + libecal/libical (client side) + EDS (server side, stored in iCalendar 2.0 text file) 
'''Used by''': calendar app ([mailto:sirisha.muppavarapu@intel.com Sirisha Muppavarapu]), clock app (originally [mailto:todd.e.brandt@intel.com Todd Brandt])

'''Advantages of mKCal''':
* partial loading of data from sqlite (not used by calendar app); EDS holds complete calendar in memory
* incremental changes to database; EDS must rewrite complete file
'''Disadvantages of mKCal (current implementation)''':
* only provides single "database changed" signal, forces apps to reload everything (not currently done in calendar app); EDS sends add/update/delete notifications to apps watching a calendar

Plan:
* use upstream KDE version of KCalCore (current MeeGo version has semantic differences in event->dtEnd())
* write [[/KCalCore-EDS|storage which uses libecal/EDS]]
* [[/eds-improvements|EDS improvements]]

== Contact Storage ==

'''Maemo solution''': QtContacts (API) + QtContacts-Tracker (glue code) + Tracker (storage) + contactsd (updating presence information in Tracker) 
'''EDS proposal''': QtContacts (API) + [[/QtContacts storage plugin|QtContacts-EDS]] + libebook (client side) + EDS (server side, storage of vCards in Berkley DB); libfolks as replacement for contactsd 
'''Used by''': libseaside/meego-app-contacts/meego-handset-people/ContactPicker.qml ([mailto:connie.berardi@intel.com Connie Berardi] and [mailto:kaitlin.rupert@intel.com]), SMS and Messaging apps ([mailto:benjamin.t.drucker@intel.com Ben Drucker]), various parts of Tablet UX via QML binding, obexd for Phone Book Access Protocol (PBAP) plugin) 

'''Advantages of Tracker''':
* supports potential future use cases (combining data from different categories, partial reading/writing, fine-grained annotations on data origin)
* better searching
* scalability (?)
* read performance (?)

'''Disadvantages of Tracker''':
* data protection missing in both EDS and Tracker, but less obvious how to implement it in Tracker
* slow write performance in QtContacts-Tracker (?)

'''Plan''':
* write a QtContacts storage plugin ([[/QtContacts storage plugin|details on QtContacts-EDS]]),
* [[/eds-improvements|EDS improvements]]
* libfolks provides a QtContacts API (in addition to native APIs) and can use either Tracker or EDS directly as backends. Additional work will be needed to improve the EDS part and performance/memory usage.

'''Opens''':
* obexd has PBAP plugin for EDS, needs to be tested/improved/adapted (photo support, vCard 2.1/3.0); can't use QtContacts-EDS because obexd accesses Tracker directly
* [http://lists.meego.com/pipermail/meego-dev/2011-March/482065.html communication history], currently done with QSettings in dialer app - how will that be done in the future?

== Mail Storage and Transports ==

'''Maemo solution''': QtMobility/QtMessaging (API) + Qt Messaging Framework (QMF, actual implementation) 
'''EDS proposal''': QtMobility/QtMessaging (API) + QMF-compatible API (?) + Camel library (part of EDS, but not running in the daemon itself yet) 
'''Used by''': mail app ([mailto:carl.wong@intel.com Carl Wong]), SMS storage plugin ([mailto:benjamin.t.drucker@intel.com Ben Drucker])

'''Advantages of QMF''':
* already works as a stand-alone daemon

'''Plan A [[/QMF client lib substitution|(details)]]'''
* kudos to [mailto:srinivasa.ragavan.venkateswaran@intel.com Srinivasa (Srini) Venkateswaran] for this proposal
* write simplistic server which runs Camel
* replace QMF client library with one which accesses that server - ideally this library is at least QMF API source code compatible (=> adapting apps and QtMobility/QtMessaging requires recompilation, not rewriting)
* account setup UI

Some possible variations of plan A:
* rewrite mail app and QtMobility/QtMessaging to use Camel daemon via D-Bus
* QMF (source code) compatible replacement, used by mail app and Messaging (proposal above)
* rewrite mail app to use Messaging, rewrite Messaging to use Camel via D-Bus

'''Plan B''':
* keep QMF as mail infrastructure

== Data Synchronization ==
'''Maemo solution''': Buteo Sync Framework, Buteo SyncML, Buteo Sync Plugins, Buteo Media Transfer Protocol (MTP) 
'''Alternative''': SyncEvolution, Synthesis SyncML, Buteo Media Transfer Protocol 

'''Advantages of Buteo''':
* plugable sync engines, more sophisticated scheduling of time-based syncs
* Tablet Google Contact sync preserves properties not supported by Google

'''Disadvantages of Buteo''':
* incomplete, untested (in MeeGo)
* no support for incoming SyncML over OBEX/Bluetooth

'''Step 1''':
* keep Buteo Sync Framework
* replace SyncML engine for Google Contact sync in Tablet with SyncEvolution + Synthesis:
** The [http://meego.gitorious.org/meego-middleware/syncevolution/blobs/master/src/backends/buteo/ButeoBridge.cpp existing Buteo sync plugin] must also [https://bugs.meego.com/show_bug.cgi?id=15031 support Google Contacts]. No support for any other SyncML peer. This is the only SyncML peer which was tested with Buteo in MeeGo (done by the Intel Tablet team), so not supporting other SyncML peers in step 1 is not a regression.
** [https://bugs.meego.com/show_bug.cgi?id=15030 Preserving local extensions] when synchronizing with Google depends on [https://bugs.meego.com/show_bug.cgi?id=15029 hard-coding capabilities of that peer] and [https://bugs.meego.com/show_bug.cgi?id=15030 support for unknown properties].
** Google Contact sync might run in parallel with CalDAV sync. The SyncEvolution sync plugin must support that. Must [https://bugs.meego.com/show_bug.cgi?id=681 replace global variables].

'''Step 2''':
* rewrite QML settings backend to use SyncEvolution D-Bus API
* remove Buteo msyncd/framework, run Buteo MTP as part of syncevo-dbus-server or stand-alone

'''Further improvements to SyncEvolution/MTP''':
* code refactoring of libsynthesis to support non-SyncML sync scenarios and plain C code which needs data conversion (obexd plugin?)
* support push sync
* redesign daemon to run syncs in forked processes (security, responsiveness of D-Bus API)
* device-to-device sync over WLAN
* MTP over WLAN and Bluetooth

Architecture/planning/evolution-data-server/eds-improvements

2011-04-05T09:49:35Z

Pohly: added ideas for sending only UIDs in contact view and setting EBook query flags

Architecture/planning/evolution-data-server/eds-improvements

2011-04-04T11:11:49Z

Pohly: /* change tracking */

Architecture/planning/evolution-data-server

2011-04-04T11:10:26Z

Pohly: /* Mail Storage and Transports */

== Introduction ==

The architecture decision to make the transition from Nokia-supported components for contacts and calendar data (PIM) storage, email storage and transports, and sync back to the components used in MeeGo Netbook (Evolution Data Server and SyncEvolution) [http://lists.meego.com/pipermail/meego-dev/2011-March/481890.html was announced publicly] on March 7th. Planning the execution of that change is currently (end of March 2011) in progress.

This page gathers information about the PIM + mail storages and sync. Main author and point of contact is [mailto:patrick.ohly@intel.com Patrick Ohly]. It includes information contributed by various people, mentioned with email address below.

Information that has not been confirmed is marked with a question mark.

== Calendar Storage ==

'''Maemo solution''': QtMobility/QtOrganizer (API) + KCalCore (KDE) + modifications + mKCal (sqlite storage) 
'''EDS proposal''': QtMobility/QtOrganizer (API) + [[/KCalCore-EDS]] + libecal/libical (client side) + EDS (server side, stored in iCalendar 2.0 text file) 
'''Used by''': calendar app ([mailto:sirisha.muppavarapu@intel.com Sirisha Muppavarapu]), clock app (originally [mailto:todd.e.brandt@intel.com Todd Brandt])

'''Advantages of mKCal''':
* partial loading of data from sqlite (not used by calendar app); EDS holds complete calendar in memory
* incremental changes to database; EDS must rewrite complete file
'''Disadvantages of mKCal (current implementation)''':
* only provides single "database changed" signal, forces apps to reload everything (not currently done in calendar app); EDS sends add/update/delete notifications to apps watching a calendar

Plan:
* use upstream KDE version of KCalCore (current MeeGo version has semantic differences in event->dtEnd())
* write [[/KCalCore-EDS|storage which uses libecal/EDS]]
* [[/eds-improvements|EDS improvements]]

== Contact Storage ==

'''Maemo solution''': QtContacts (API) + QtContacts-Tracker (glue code) + Tracker (storage) + contactsd (updating presence information in Tracker) 
'''EDS proposal''': QtContacts (API) + [[/QtContacts storage plugin|QtContacts-EDS] + libebook (client side) + EDS (server side, storage of vCards in Berkley DB); libfolks as replacement for contactsd 
'''Used by''': libseaside/meego-app-contacts/meego-handset-people/ContactPicker.qml ([mailto:connie.berardi@intel.com Connie Berardi] and [mailto:kaitlin.rupert@intel.com]), SMS and Messaging apps ([mailto:benjamin.t.drucker@intel.com Ben Drucker]), various parts of Tablet UX via QML binding, obexd for Phone Book Access Protocol (PBAP) plugin) 

'''Advantages of Tracker''':
* supports potential future use cases (combining data from different categories, partial reading/writing, fine-grained annotations on data origin)
* better searching
* scalability (?)
* read performance (?)

'''Disadvantages of Tracker''':
* data protection missing in both EDS and Tracker, but less obvious how to implement it in Tracker
* slow write performance in QtContacts-Tracker (?)

'''Plan''':
* write a QtContacts storage plugin ([[/QtContacts storage plugin|details on QtContacts-EDS]]),
* [[/eds-improvements|EDS improvements]]
* libfolks provides a QtContacts API (in addition to native APIs) and can use either Tracker or EDS directly as backends. Additional work will be needed to improve the EDS part and performance/memory usage.

'''Opens''':
* obexd has PBAP plugin for EDS, needs to be tested/improved/adapted (photo support, vCard 2.1/3.0); can't use QtContacts-EDS because obexd accesses Tracker directly
* [http://lists.meego.com/pipermail/meego-dev/2011-March/482065.html communication history], currently done with QSettings in dialer app - how will that be done in the future?

== Mail Storage and Transports ==

'''Maemo solution''': QtMobility/QtMessaging (API) + Qt Messaging Framework (QMF, actual implementation) 
'''EDS proposal''': QtMobility/QtMessaging (API) + QMF-compatible API (?) + Camel library (part of EDS, but not running in the daemon itself yet) 
'''Used by''': mail app ([mailto:carl.wong@intel.com Carl Wong]), SMS storage plugin ([mailto:benjamin.t.drucker@intel.com Ben Drucker])

'''Advantages of QMF''':
* already works as a stand-alone daemon

'''Plan A [[/QMF client lib substitution|(details)]]'''
* kudos to [mailto:srinivasa.ragavan.venkateswaran@intel.com Srinivasa (Srini) Venkateswaran] for this proposal
* write simplistic server which runs Camel
* replace QMF client library with one which accesses that server - ideally this library is at least QMF API source code compatible (=> adapting apps and QtMobility/QtMessaging requires recompilation, not rewriting)
* account setup UI

Some possible variations of plan A:
* rewrite mail app and QtMobility/QtMessaging to use Camel daemon via D-Bus
* QMF (source code) compatible replacement, used by mail app and Messaging (proposal above)
* rewrite mail app to use Messaging, rewrite Messaging to use Camel via D-Bus

'''Plan B''':
* keep QMF as mail infrastructure

== Data Synchronization ==
'''Maemo solution''': Buteo Sync Framework, Buteo SyncML, Buteo Sync Plugins, Buteo Media Transfer Protocol (MTP) 
'''Alternative''': SyncEvolution, Synthesis SyncML, Buteo Media Transfer Protocol 

'''Advantages of Buteo''':
* plugable sync engines, more sophisticated scheduling of time-based syncs
* Tablet Google Contact sync preserves properties not supported by Google

'''Disadvantages of Buteo''':
* incomplete, untested (in MeeGo)
* no support for incoming SyncML over OBEX/Bluetooth

'''Step 1''':
* keep Buteo Sync Framework
* replace SyncML engine for Google Contact sync in Tablet with SyncEvolution + Synthesis:
** The [http://meego.gitorious.org/meego-middleware/syncevolution/blobs/master/src/backends/buteo/ButeoBridge.cpp existing Buteo sync plugin] must also [https://bugs.meego.com/show_bug.cgi?id=15031 support Google Contacts]. No support for any other SyncML peer. This is the only SyncML peer which was tested with Buteo in MeeGo (done by the Intel Tablet team), so not supporting other SyncML peers in step 1 is not a regression.
** [https://bugs.meego.com/show_bug.cgi?id=15030 Preserving local extensions] when synchronizing with Google depends on [https://bugs.meego.com/show_bug.cgi?id=15029 hard-coding capabilities of that peer] and [https://bugs.meego.com/show_bug.cgi?id=15030 support for unknown properties].
** Google Contact sync might run in parallel with CalDAV sync. The SyncEvolution sync plugin must support that. Must [https://bugs.meego.com/show_bug.cgi?id=681 replace global variables].

'''Step 2''':
* rewrite QML settings backend to use SyncEvolution D-Bus API
* remove Buteo msyncd/framework, run Buteo MTP as part of syncevo-dbus-server or stand-alone

'''Further improvements to SyncEvolution/MTP''':
* code refactoring of libsynthesis to support non-SyncML sync scenarios and plain C code which needs data conversion (obexd plugin?)
* support push sync
* redesign daemon to run syncs in forked processes (security, responsiveness of D-Bus API)
* device-to-device sync over WLAN
* MTP over WLAN and Bluetooth

Architecture/planning/evolution-data-server

2011-04-04T11:05:48Z

Pohly: /* Contact Storage */

== Introduction ==

The architecture decision to make the transition from Nokia-supported components for contacts and calendar data (PIM) storage, email storage and transports, and sync back to the components used in MeeGo Netbook (Evolution Data Server and SyncEvolution) [http://lists.meego.com/pipermail/meego-dev/2011-March/481890.html was announced publicly] on March 7th. Planning the execution of that change is currently (end of March 2011) in progress.

This page gathers information about the PIM + mail storages and sync. Main author and point of contact is [mailto:patrick.ohly@intel.com Patrick Ohly]. It includes information contributed by various people, mentioned with email address below.

Information that has not been confirmed is marked with a question mark.

== Calendar Storage ==

'''Maemo solution''': QtMobility/QtOrganizer (API) + KCalCore (KDE) + modifications + mKCal (sqlite storage) 
'''EDS proposal''': QtMobility/QtOrganizer (API) + [[/KCalCore-EDS]] + libecal/libical (client side) + EDS (server side, stored in iCalendar 2.0 text file) 
'''Used by''': calendar app ([mailto:sirisha.muppavarapu@intel.com Sirisha Muppavarapu]), clock app (originally [mailto:todd.e.brandt@intel.com Todd Brandt])

'''Advantages of mKCal''':
* partial loading of data from sqlite (not used by calendar app); EDS holds complete calendar in memory
* incremental changes to database; EDS must rewrite complete file
'''Disadvantages of mKCal (current implementation)''':
* only provides single "database changed" signal, forces apps to reload everything (not currently done in calendar app); EDS sends add/update/delete notifications to apps watching a calendar

Plan:
* use upstream KDE version of KCalCore (current MeeGo version has semantic differences in event->dtEnd())
* write [[/KCalCore-EDS|storage which uses libecal/EDS]]
* [[/eds-improvements|EDS improvements]]

== Contact Storage ==

'''Maemo solution''': QtContacts (API) + QtContacts-Tracker (glue code) + Tracker (storage) + contactsd (updating presence information in Tracker) 
'''EDS proposal''': QtContacts (API) + [[/QtContacts storage plugin|QtContacts-EDS] + libebook (client side) + EDS (server side, storage of vCards in Berkley DB); libfolks as replacement for contactsd 
'''Used by''': libseaside/meego-app-contacts/meego-handset-people/ContactPicker.qml ([mailto:connie.berardi@intel.com Connie Berardi] and [mailto:kaitlin.rupert@intel.com]), SMS and Messaging apps ([mailto:benjamin.t.drucker@intel.com Ben Drucker]), various parts of Tablet UX via QML binding, obexd for Phone Book Access Protocol (PBAP) plugin) 

'''Advantages of Tracker''':
* supports potential future use cases (combining data from different categories, partial reading/writing, fine-grained annotations on data origin)
* better searching
* scalability (?)
* read performance (?)

'''Disadvantages of Tracker''':
* data protection missing in both EDS and Tracker, but less obvious how to implement it in Tracker
* slow write performance in QtContacts-Tracker (?)

'''Plan''':
* write a QtContacts storage plugin ([[/QtContacts storage plugin|details on QtContacts-EDS]]),
* [[/eds-improvements|EDS improvements]]
* libfolks provides a QtContacts API (in addition to native APIs) and can use either Tracker or EDS directly as backends. Additional work will be needed to improve the EDS part and performance/memory usage.

'''Opens''':
* obexd has PBAP plugin for EDS, needs to be tested/improved/adapted (photo support, vCard 2.1/3.0); can't use QtContacts-EDS because obexd accesses Tracker directly
* [http://lists.meego.com/pipermail/meego-dev/2011-March/482065.html communication history], currently done with QSettings in dialer app - how will that be done in the future?

== Mail Storage and Transports ==

'''Maemo solution''': QtMobility/QtMessaging API + Qt Messaging Framework (QMF, actual implementation) 
'''EDS''': QMF-compatible API (?) + Camel library (part of EDS, but not running in the daemon itself yet) 
'''Used by''': mail app ([mailto:carl.wong@intel.com Carl Wong]), SMS storage plugin ([mailto:benjamin.t.drucker@intel.com Ben Drucker])

'''Advantages of QMF''':
* already works as a stand-alone daemon

'''Plan A [[/QMF client lib substitution|(details)]]'''
* kudos to [mailto:srinivasa.ragavan.venkateswaran@intel.com Srinivasa (Srini) Venkateswaran] for this proposal
* write simplistic server which runs Camel
* replace QMF client library with one which accesses that server - ideally this library is at least QMF API source code compatible (=> adapting apps requires recompilation, not rewriting)
* account setup UI

'''Plan B''':
* keep QMF as mail infrastructure

== Data Synchronization ==
'''Maemo solution''': Buteo Sync Framework, Buteo SyncML, Buteo Sync Plugins, Buteo Media Transfer Protocol (MTP) 
'''Alternative''': SyncEvolution, Synthesis SyncML, Buteo Media Transfer Protocol 

'''Advantages of Buteo''':
* plugable sync engines, more sophisticated scheduling of time-based syncs
* Tablet Google Contact sync preserves properties not supported by Google

'''Disadvantages of Buteo''':
* incomplete, untested (in MeeGo)
* no support for incoming SyncML over OBEX/Bluetooth

'''Step 1''':
* keep Buteo Sync Framework
* replace SyncML engine for Google Contact sync in Tablet with SyncEvolution + Synthesis:
** The [http://meego.gitorious.org/meego-middleware/syncevolution/blobs/master/src/backends/buteo/ButeoBridge.cpp existing Buteo sync plugin] must also [https://bugs.meego.com/show_bug.cgi?id=15031 support Google Contacts]. No support for any other SyncML peer. This is the only SyncML peer which was tested with Buteo in MeeGo (done by the Intel Tablet team), so not supporting other SyncML peers in step 1 is not a regression.
** [https://bugs.meego.com/show_bug.cgi?id=15030 Preserving local extensions] when synchronizing with Google depends on [https://bugs.meego.com/show_bug.cgi?id=15029 hard-coding capabilities of that peer] and [https://bugs.meego.com/show_bug.cgi?id=15030 support for unknown properties].
** Google Contact sync might run in parallel with CalDAV sync. The SyncEvolution sync plugin must support that. Must [https://bugs.meego.com/show_bug.cgi?id=681 replace global variables].

'''Step 2''':
* rewrite QML settings backend to use SyncEvolution D-Bus API
* remove Buteo msyncd/framework, run Buteo MTP as part of syncevo-dbus-server or stand-alone

'''Further improvements to SyncEvolution/MTP''':
* code refactoring of libsynthesis to support non-SyncML sync scenarios and plain C code which needs data conversion (obexd plugin?)
* support push sync
* redesign daemon to run syncs in forked processes (security, responsiveness of D-Bus API)
* device-to-device sync over WLAN
* MTP over WLAN and Bluetooth

Architecture/planning/evolution-data-server

2011-04-04T10:57:04Z

Pohly: /* Calendar Storage */

== Introduction ==

The architecture decision to make the transition from Nokia-supported components for contacts and calendar data (PIM) storage, email storage and transports, and sync back to the components used in MeeGo Netbook (Evolution Data Server and SyncEvolution) [http://lists.meego.com/pipermail/meego-dev/2011-March/481890.html was announced publicly] on March 7th. Planning the execution of that change is currently (end of March 2011) in progress.

This page gathers information about the PIM + mail storages and sync. Main author and point of contact is [mailto:patrick.ohly@intel.com Patrick Ohly]. It includes information contributed by various people, mentioned with email address below.

Information that has not been confirmed is marked with a question mark.

== Calendar Storage ==

'''Maemo solution''': QtMobility/QtOrganizer (API) + KCalCore (KDE) + modifications + mKCal (sqlite storage) 
'''EDS proposal''': QtMobility/QtOrganizer (API) + [[/KCalCore-EDS]] + libecal/libical (client side) + EDS (server side, stored in iCalendar 2.0 text file) 
'''Used by''': calendar app ([mailto:sirisha.muppavarapu@intel.com Sirisha Muppavarapu]), clock app (originally [mailto:todd.e.brandt@intel.com Todd Brandt])

'''Advantages of mKCal''':
* partial loading of data from sqlite (not used by calendar app); EDS holds complete calendar in memory
* incremental changes to database; EDS must rewrite complete file
'''Disadvantages of mKCal (current implementation)''':
* only provides single "database changed" signal, forces apps to reload everything (not currently done in calendar app); EDS sends add/update/delete notifications to apps watching a calendar

Plan:
* use upstream KDE version of KCalCore (current MeeGo version has semantic differences in event->dtEnd())
* write [[/KCalCore-EDS|storage which uses libecal/EDS]]
* [[/eds-improvements|EDS improvements]]

== Contact Storage ==

'''Maemo solution''': QtContacts (API) + QtContacts-Tracker (glue code) + Tracker (storage) 
'''EDS''': QtContacts (API) + libebook (client side) + EDS (server side, storage of vCards in Berkley DB) 
'''Used by''': libseaside/meego-app-contacts/meego-handset-people/ContactPicker.qml ([mailto:connie.berardi@intel.com Connie Berardi] and [mailto:kaitlin.rupert@intel.com]), SMS and Messaging apps ([mailto:benjamin.t.drucker@intel.com Ben Drucker]), various parts of Tablet UX via QML binding, obexd for Phone Book Access Protocol (PBAP) plugin, libfolks) 

'''Advantages of Tracker''':
* supports potential future use cases (combining data from different categories, partial reading/writing, fine-grained annotations on data origin)
* better searching
* scalability (?)
* read performance (?)

'''Disadvantages of Tracker''':
* data protection missing in both EDS and Tracker, but less obvious how to implement it in Tracker
* slow write performance in QtContacts-Tracker (?)

'''Plan''':
* write a QtContacts storage plugin ([[/QtContacts storage plugin|details on QtContacts-EDS]]),
* [[/eds-improvements|EDS improvements]]

'''Opens''':
* obexd has PBAP plugin for EDS, needs to be tested/improved/adapted (photo support, vCard 2.1/3.0); can't use QtContacts-EDS because obexd accesses Tracker directly
* [http://lists.meego.com/pipermail/meego-dev/2011-March/482065.html communication history], currently done with QSettings in dialer app - how will that be done in the future?
* correlate presence information from Telepathy with address book ("who is online?") - was done with contactsd+Tracker (not used by us), meant to be done with libfolks

== Mail Storage and Transports ==

'''Maemo solution''': QtMobility/QtMessaging API + Qt Messaging Framework (QMF, actual implementation) 
'''EDS''': QMF-compatible API (?) + Camel library (part of EDS, but not running in the daemon itself yet) 
'''Used by''': mail app ([mailto:carl.wong@intel.com Carl Wong]), SMS storage plugin ([mailto:benjamin.t.drucker@intel.com Ben Drucker])

'''Advantages of QMF''':
* already works as a stand-alone daemon

'''Plan A [[/QMF client lib substitution|(details)]]'''
* kudos to [mailto:srinivasa.ragavan.venkateswaran@intel.com Srinivasa (Srini) Venkateswaran] for this proposal
* write simplistic server which runs Camel
* replace QMF client library with one which accesses that server - ideally this library is at least QMF API source code compatible (=> adapting apps requires recompilation, not rewriting)
* account setup UI

'''Plan B''':
* keep QMF as mail infrastructure

== Data Synchronization ==
'''Maemo solution''': Buteo Sync Framework, Buteo SyncML, Buteo Sync Plugins, Buteo Media Transfer Protocol (MTP) 
'''Alternative''': SyncEvolution, Synthesis SyncML, Buteo Media Transfer Protocol 

'''Advantages of Buteo''':
* plugable sync engines, more sophisticated scheduling of time-based syncs
* Tablet Google Contact sync preserves properties not supported by Google

'''Disadvantages of Buteo''':
* incomplete, untested (in MeeGo)
* no support for incoming SyncML over OBEX/Bluetooth

'''Step 1''':
* keep Buteo Sync Framework
* replace SyncML engine for Google Contact sync in Tablet with SyncEvolution + Synthesis:
** The [http://meego.gitorious.org/meego-middleware/syncevolution/blobs/master/src/backends/buteo/ButeoBridge.cpp existing Buteo sync plugin] must also [https://bugs.meego.com/show_bug.cgi?id=15031 support Google Contacts]. No support for any other SyncML peer. This is the only SyncML peer which was tested with Buteo in MeeGo (done by the Intel Tablet team), so not supporting other SyncML peers in step 1 is not a regression.
** [https://bugs.meego.com/show_bug.cgi?id=15030 Preserving local extensions] when synchronizing with Google depends on [https://bugs.meego.com/show_bug.cgi?id=15029 hard-coding capabilities of that peer] and [https://bugs.meego.com/show_bug.cgi?id=15030 support for unknown properties].
** Google Contact sync might run in parallel with CalDAV sync. The SyncEvolution sync plugin must support that. Must [https://bugs.meego.com/show_bug.cgi?id=681 replace global variables].

'''Step 2''':
* rewrite QML settings backend to use SyncEvolution D-Bus API
* remove Buteo msyncd/framework, run Buteo MTP as part of syncevo-dbus-server or stand-alone

'''Further improvements to SyncEvolution/MTP''':
* code refactoring of libsynthesis to support non-SyncML sync scenarios and plain C code which needs data conversion (obexd plugin?)
* support push sync
* redesign daemon to run syncs in forked processes (security, responsiveness of D-Bus API)
* device-to-device sync over WLAN
* MTP over WLAN and Bluetooth

Architecture/planning/evolution-data-server

2011-03-30T11:00:00Z

Pohly: /* Data Synchronization */

== Introduction ==

The architecture decision to make the transition from Nokia-supported components for contacts and calendar data (PIM) storage, email storage and transports, and sync back to the components used in MeeGo Netbook (Evolution Data Server and SyncEvolution) [http://lists.meego.com/pipermail/meego-dev/2011-March/481890.html was announced publicly] on March 7th. Planning the execution of that change is currently (end of March 2011) in progress.

This page gathers information about the PIM + mail storages and sync. Main author and point of contact is [mailto:patrick.ohly@intel.com Patrick Ohly]. It includes information contributed by various people, mentioned with email address below.

Information that has not been confirmed is marked with a question mark.

== Calendar Storage ==

'''Maemo solution''': QtMobility/QtOrganizer (API) + KCalCore (KDE) + modifications + mKCal (sqlite storage) 
'''EDS''': QtMobility/QtOrganizer (API) + libecal/libical (client side) + EDS (server side, stored in iCalendar 2.0 text file) 
'''Used by''': calendar app ([mailto:sirisha.muppavarapu@intel.com Sirisha Muppavarapu]), clock app (originally [mailto:todd.e.brandt@intel.com Todd Brandt], currently no active maintainer (?))

'''Advantages of mKCal''':
* partial loading of data from sqlite (theoretic, in practice it was too hard to use and/or faulty); EDS holds complete calendar in memory
* incremental changes to database; EDS must rewrite complete file
'''Disadvantages of mKCal''':
* only provides single "database changed" signal, forces apps to reload everything (not currently done in calendar app); EDS sends add/update/delete notifications to apps watching a calendar
* until recently, iCalendar 2.0 support was faulty

Plan:
* use upstream KDE version of KCalCore
* write storage which uses libecal/EDS
* [[/eds-improvements|EDS improvements]]

== Contact Storage ==

'''Maemo solution''': QtContacts (API) + QtContacts-Tracker (glue code) + Tracker (storage) 
'''EDS''': QtContacts (API) + libebook (client side) + EDS (server side, storage of vCards in Berkley DB) 
'''Used by''': libseaside/meego-app-contacts/meego-handset-people/ContactPicker.qml ([mailto:connie.berardi@intel.com Connie Berardi] and [mailto:kaitlin.rupert@intel.com]), SMS and Messaging apps ([mailto:benjamin.t.drucker@intel.com Ben Drucker]), various parts of Tablet UX via QML binding, obexd for Phone Book Access Protocol (PBAP) plugin, libfolks) 

'''Advantages of Tracker''':
* supports potential future use cases (combining data from different categories, partial reading/writing, fine-grained annotations on data origin)
* better searching
* scalability (?)
* read performance (?)

'''Disadvantages of Tracker''':
* data protection missing in both EDS and Tracker, but less obvious how to implement it in Tracker
* slow write performance in QtContacts-Tracker (?)

'''Plan''':
* write a QtContacts storage plugin ([[/QtContacts storage plugin|details on QtContacts-EDS]]),
* [[/eds-improvements|EDS improvements]]

'''Opens''':
* obexd has PBAP plugin for EDS, needs to be tested/improved/adapted (photo support, vCard 2.1/3.0); can't use QtContacts-EDS because obexd accesses Tracker directly
* [http://lists.meego.com/pipermail/meego-dev/2011-March/482065.html communication history], currently done with QSettings in dialer app - how will that be done in the future?
* correlate presence information from Telepathy with address book ("who is online?") - was done with contactsd+Tracker (not used by us), meant to be done with libfolks

== Mail Storage and Transports ==

'''Maemo solution''': QtMobility/QtMessaging API + Qt Messaging Framework (QMF, actual implementation) 
'''EDS''': QMF-compatible API (?) + Camel library (part of EDS, but not running in the daemon itself yet) 
'''Used by''': mail app ([mailto:carl.wong@intel.com Carl Wong]), SMS storage plugin ([mailto:benjamin.t.drucker@intel.com Ben Drucker])

'''Advantages of QMF''':
* already works as a stand-alone daemon

'''Plan A [[/QMF client lib substitution|(details)]]'''
* kudos to [mailto:srinivasa.ragavan.venkateswaran@intel.com Srinivasa (Srini) Venkateswaran] for this proposal
* write simplistic server which runs Camel
* replace QMF client library with one which accesses that server - ideally this library is at least QMF API source code compatible (=> adapting apps requires recompilation, not rewriting)
* account setup UI

'''Plan B''':
* keep QMF as mail infrastructure

== Data Synchronization ==
'''Maemo solution''': Buteo Sync Framework, Buteo SyncML, Buteo Sync Plugins, Buteo Media Transfer Protocol (MTP) 
'''Alternative''': SyncEvolution, Synthesis SyncML, Buteo Media Transfer Protocol 

'''Advantages of Buteo''':
* plugable sync engines, more sophisticated scheduling of time-based syncs
* Tablet Google Contact sync preserves properties not supported by Google

'''Disadvantages of Buteo''':
* incomplete, untested (in MeeGo)
* no support for incoming SyncML over OBEX/Bluetooth

'''Step 1''':
* keep Buteo Sync Framework
* replace SyncML engine for Google Contact sync in Tablet with SyncEvolution + Synthesis:
** The [http://meego.gitorious.org/meego-middleware/syncevolution/blobs/master/src/backends/buteo/ButeoBridge.cpp existing Buteo sync plugin] must also [https://bugs.meego.com/show_bug.cgi?id=15031 support Google Contacts]. No support for any other SyncML peer. This is the only SyncML peer which was tested with Buteo in MeeGo (done by the Intel Tablet team), so not supporting other SyncML peers in step 1 is not a regression.
** [https://bugs.meego.com/show_bug.cgi?id=15030 Preserving local extensions] when synchronizing with Google depends on [https://bugs.meego.com/show_bug.cgi?id=15029 hard-coding capabilities of that peer] and [https://bugs.meego.com/show_bug.cgi?id=15030 support for unknown properties].
** Google Contact sync might run in parallel with CalDAV sync. The SyncEvolution sync plugin must support that. Must [https://bugs.meego.com/show_bug.cgi?id=681 replace global variables].

'''Step 2''':
* rewrite QML settings backend to use SyncEvolution D-Bus API
* remove Buteo msyncd/framework, run Buteo MTP as part of syncevo-dbus-server or stand-alone

'''Further improvements to SyncEvolution/MTP''':
* code refactoring of libsynthesis to support non-SyncML sync scenarios and plain C code which needs data conversion (obexd plugin?)
* support push sync
* redesign daemon to run syncs in forked processes (security, responsiveness of D-Bus API)
* device-to-device sync over WLAN
* MTP over WLAN and Bluetooth

Architecture

2011-03-30T10:27:37Z

Pohly: /* Upcoming Features */

== MeeGo Architecture ==

MeeGo architecture team is responsible for defining and managing the MeeGo architecture. MeeGo architecture consists of Core OS layer and number of UX verticals on top the Core OS layer. The architecture team decides which component to use for the functionality needed in MeeGo with the objective of consistency inside the Core OS and to the applications that run above it.

== Team ==

* '''[http://meego.com/users/arjan Arjan van de Ven]''', Chief Architect, responsible for MeeGo architecture
* '''[http://meego.com/users/poussa Sakari Poussa]''', Core OS Architect, responsible for Core OS architecture
* '''[http://meego.com/users/mythi Mikko Ylinen]''', Handset UX Architect, responsible for Handset UX architecture
* '''[http://meego.com/users/sunilsaxena Sunil Saxena]''', Core OS Architect, responsible for Core OS architecture

== Communication ==

* [http://lists.meego.com/listinfo/meego-architecture MeeGo architecture mailing list]

== Process ==

* Architecture team meets once a week. Currently the meetings are not public.
* Agenda and minutes of the meetings will be posted to the meego-architecture mailing list
* Anyone can propose topics to the architecture team agenda
* Architecture topics can and should be discussed on meego-architecture mailing list
* Architecture team is responsible of making the decision in case consensus is not reached

=== Process Improvement Topics ===

* How to make the architecture meetings open. Not all the topics can be open but most can be. Examples of non-open parts includes topics which involves IPR, legal, patent, business, product or schedule sensitive material.

== Documentation ==

* Developer Documentation: APIs, tutorials, videos, examples ([http://developer.meego.com]), to be published soon
* Architecture Documentation: High level architecture pictures and description ([http://meego.com/developers/meego-architecture])
* Developer and Subsystem Documentation: Detailed technical description of each MeeGo subsystem. Guidelines for developers working on MeeGo. ([[Architecture/Documentation]])

== Meetings ==

* [[Architecture/Meetings]] - Meetings - agenda, minutes

== Upcoming Features ==

MeeGo Bugzilla lists the following features for MeeGo 1.2. The below proposal are all accepted and are on their way to MeeGo 1.2 release.

* Display backlight and keyboard backlight control: [http://bugs.meego.com/show_bug.cgi?id=5525 5525], [http://bugs.meego.com/show_bug.cgi?id=5526 5526], [http://bugs.meego.com/show_bug.cgi?id=5527 5527], [http://bugs.meego.com/show_bug.cgi?id=5528 5528]
** Proposal 1: Maemo 6 MCE
*** ''MCE provides activity monitoring and notifications via D-Bus, controls display and backlight, ALS reading and display tuning, airplane mode''

* Sharing: [http://bugs.meego.com/show_bug.cgi?id=8179 8179], [http://bugs.meego.com/show_bug.cgi?id=8180 8180], [http://bugs.meego.com/show_bug.cgi?id=8181 8181]
** Proposal 1: Maemo6 Sharing framework
*** ''Sharing framework provides a unified API for sharing files via, e.g., BT, email, web services. It includes webupload engine and an API for transfer UI''

* Qt style APIs (that are not covered by Qt Mobility) for display backlight control, alarm/time, heartbeat, system state, thermal
** Proposal 1: Maemo6 QmSystem
*** ''QmSystem provides Qt style public APIs for various system services that are not covered by Qt Mobility''

* Profiles: [http://bugs.meego.com/show_bug.cgi?id=5771 5771], [http://bugs.meego.com/show_bug.cgi?id=5750 5750], [http://bugs.meego.com/show_bug.cgi?id=2889 2889]
** Proposal 1: Maemo6 profiled
*** ''profiled provides a daemon and libraries to access and control profiles related data in the device. The libprofile (C) and libprofile-qt (Qt) are interfaces for the profile client to connect to the server using D-Bus. The profiled data is stored in ‘ini’ files which can be customized per different releases.''

* Ringtones+feedback: [http://bugs.meego.com/show_bug.cgi?id=2889 2889]
** Proposal 1: Maemo6 NGF (non-graphic feedback)
*** ''The device has functionality to alert user of a call, alarms and notification (SMS, email, chat, system update) events. Events may or may not have a graphical part and it may have different behavior depending on the system state. Example of this is receiving an SMS message when there is no other activity and SMS message during a call. NGF provides a unified API for apps to request logical events. The actions (e.g,. play/show LED+audio+vibra) are combined in NGF and consistent look&feel is provided''.

* PIM Storage in Evolution Data Server (EDS) and email via Camel, SyncEvolution as sync engine
** architecture decision to move towards EDS and Camel [http://lists.meego.com/pipermail/meego-dev/2011-March/481890.html announced]
** planning [[/planning/evolution-data-server|in progress]]

== Tools ==

Architecture tools

* Architecture navigation tool - able to browse meego packages and visually see the dependencies (coming in Nov)

Architecture/planning/evolution-data-server/eds-improvements

2011-03-29T15:10:33Z

Pohly:

Architecture/planning/evolution-data-server/eds-improvements

2011-03-29T14:20:29Z

Pohly: Created page with "This page describes improvements that are desirable or even essential for good performance of Evolution Data Server (EDS) as PIM storage in MeeGo. All of these changes should be…"

Architecture/planning/evolution-data-server/QtContacts storage plugin

2011-03-29T12:15:41Z

Pohly: Created page with "== QtContacts-EDS == Can be based on http://www.qt.gitorious.org/qt-mobility/contacts/blobs/master/plugins/contacts/maemo5/qcontactabook.cpp existing Harmattan EDS plugin, w…"

== QtContacts-EDS ==

Can be based on [[http://www.qt.gitorious.org/qt-mobility/contacts/blobs/master/plugins/contacts/maemo5/qcontactabook.cpp existing Harmattan EDS plugin]], which does not work as-is because of Nokia-specific API extensions.

Necessary changes:
* avoid ID mapping because it requires reading all contacts at startup:
** must change EDS to use 32 bit integers as local IDs for that (patch ready)
* convert between QtContacts and vCard using QtVersit, with EDS specific properties and including custom properties for QtContactDetails which have no other mapping to vCard (same approach as in SyncEvolution QtContacts backend)

Goals for initial milestone:
* full support for all QContactDetails, including custom ones, but with some limitations:
** additional fields of details which map to well-known vCard properties (full name, address) cannot be stored if they have no corresponding representation in vCard
** TODO: complete list
* change notifications (added/updated/removed)
* mapping of QtContacts filters to EDS queries, with unsupported filters implemented by QtContacts after retrieving contacts (slower than filtering in EDS daemon)
** TODO: complete list of native searches
* change notifications via ebook view: created when opened, initial data dump ignored (performance problem!), report all following changes

Goals for later milestones:
* error handling
* performance

Architecture/planning/evolution-data-server/QMF client lib substitution

2011-03-29T12:10:16Z

Pohly: Created page with "Author and contact: srinivasa.ragavan.venkateswaran@intel.com To be documented in more detail."

Author and contact: srinivasa.ragavan.venkateswaran@intel.com

To be documented in more detail.

Architecture/planning/evolution-data-server

2011-03-29T12:08:31Z

Pohly: Created page with "== Introduction == The architecture decision to make the transition from Nokia-supported components for contacts and calendar data (PIM) storage, email storage and transports, a…"

== Introduction ==

The architecture decision to make the transition from Nokia-supported components for contacts and calendar data (PIM) storage, email storage and transports, and sync back to the components used in MeeGo Netbook (Evolution Data Server and SyncEvolution) [http://lists.meego.com/pipermail/meego-dev/2011-March/481890.html was announced publicly] on March 7th. Planning the execution of that change is currently (end of March 2011) in progress.

This page gathers information about the PIM + mail storages and sync. Main author and point of contact is [mailto:patrick.ohly@intel.com Patrick Ohly]. It includes information contributed by various people, mentioned with email address below.

Information that has not been confirmed is marked with a question mark.

== Calendar Storage ==

'''Maemo solution''': QtMobility/QtOrganizer (API) + KCalCore (KDE) + modifications + mKCal (sqlite storage) 
'''EDS''': QtMobility/QtOrganizer (API) + libecal/libical (client side) + EDS (server side, stored in iCalendar 2.0 text file) 
'''Used by''': calendar app ([mailto:sirisha.muppavarapu@intel.com Sirisha Muppavarapu]), clock app (originally [mailto:todd.e.brandt@intel.com Todd Brandt], currently no active maintainer (?))

'''Advantages of mKCal''':
* partial loading of data from sqlite (theoretic, in practice it was too hard to use and/or faulty); EDS holds complete calendar in memory
* incremental changes to database; EDS must rewrite complete file
'''Disadvantages of mKCal''':
* only provides single "database changed" signal, forces apps to reload everything (not currently done in calendar app); EDS sends add/update/delete notifications to apps watching a calendar
* until recently, iCalendar 2.0 support was faulty

Plan:
* use upstream KDE version of KCalCore
* write storage which uses libecal/EDS
* [[/eds-improvements|EDS improvements]]

== Contact Storage ==

'''Maemo solution''': QtContacts (API) + QtContacts-Tracker (glue code) + Tracker (storage) 
'''EDS''': QtContacts (API) + libebook (client side) + EDS (server side, storage of vCards in Berkley DB) 
'''Used by''': libseaside/meego-app-contacts/meego-handset-people/ContactPicker.qml ([mailto:connie.berardi@intel.com Connie Berardi] and [mailto:kaitlin.rupert@intel.com]), SMS and Messaging apps ([mailto:benjamin.t.drucker@intel.com Ben Drucker]), various parts of Tablet UX via QML binding, obexd for Phone Book Access Protocol (PBAP) plugin, libfolks) 

'''Advantages of Tracker''':
* supports potential future use cases (combining data from different categories, partial reading/writing, fine-grained annotations on data origin)
* better searching
* scalability (?)
* read performance (?)

'''Disadvantages of Tracker''':
* data protection missing in both EDS and Tracker, but less obvious how to implement it in Tracker
* slow write performance in QtContacts-Tracker (?)

'''Plan''':
* write a QtContacts storage plugin ([[/QtContacts storage plugin|details on QtContacts-EDS]]),
* [[/eds-improvements|EDS improvements]]

'''Opens''':
* obexd has PBAP plugin for EDS, needs to be tested/improved/adapted (photo support, vCard 2.1/3.0); can't use QtContacts-EDS because obexd accesses Tracker directly
* [http://lists.meego.com/pipermail/meego-dev/2011-March/482065.html communication history], currently done with QSettings in dialer app - how will that be done in the future?
* correlate presence information from Telepathy with address book ("who is online?") - was done with contactsd+Tracker (not used by us), meant to be done with libfolks

== Mail Storage and Transports ==

'''Maemo solution''': QtMobility/QtMessaging API + Qt Messaging Framework (QMF, actual implementation) 
'''EDS''': QMF-compatible API (?) + Camel library (part of EDS, but not running in the daemon itself yet) 
'''Used by''': mail app ([mailto:carl.wong@intel.com Carl Wong]), SMS storage plugin ([mailto:benjamin.t.drucker@intel.com Ben Drucker])

'''Advantages of QMF''':
* already works as a stand-alone daemon

'''Plan A [[/QMF client lib substitution|(details)]]'''
* kudos to [mailto:srinivasa.ragavan.venkateswaran@intel.com Srinivasa (Srini) Venkateswaran] for this proposal
* write simplistic server which runs Camel
* replace QMF client library with one which accesses that server - ideally this library is at least QMF API source code compatible (=> adapting apps requires recompilation, not rewriting)
* account setup UI

'''Plan B''':
* keep QMF as mail infrastructure

== Data Synchronization ==
'''Maemo solution''': Buteo Sync Framework, Buteo SyncML, Buteo Sync Plugins, Buteo Media Transfer Protocol (MTP) 
'''Alternative''': SyncEvolution, Synthesis SyncML, Buteo Media Transfer Protocol 

'''Advantages of Buteo''':
* plugable sync engines, more sophisticated scheduling of time-based syncs
* Tablet Google Contact sync preserves properties not supported by Google

'''Disadvantages of Buteo''':
* incomplete, untested (in MeeGo)
* no support for incoming SyncML over OBEX/Bluetooth

'''Step 1''':
* keep Buteo Sync Framework
* replace SyncML engine for Google Contact sync in Tablet with SyncEvolution + Synthesis: SyncEvolution can already run inside Buteo, but needs Buteo configs+bridge code, still need to add the "preserve properties" part

'''Step 2''':
* rewrite QML settings backend to use SyncEvolution D-Bus API
* remove Buteo msyncd/framework, run Buteo MTP as part of syncevo-dbus-server or stand-alone

'''Further improvements to SyncEvolution/MTP''':
* code refactoring of libsynthesis to support non-SyncML sync scenarios and plain C code which needs data conversion (obexd plugin?)
* support push sync
* redesign daemon to run syncs in forked processes (security, responsiveness of D-Bus API)
* device-to-device sync over WLAN
* MTP over WLAN and Bluetooth

Architecture

2011-03-29T11:29:13Z

Pohly: /* Upcoming Features */

== MeeGo Architecture ==

MeeGo architecture team is responsible for defining and managing the MeeGo architecture. MeeGo architecture consists of Core OS layer and number of UX verticals on top the Core OS layer. The architecture team decides which component to use for the functionality needed in MeeGo with the objective of consistency inside the Core OS and to the applications that run above it.

== Team ==

* '''[http://meego.com/users/arjan Arjan van de Ven]''', Chief Architect, responsible for MeeGo architecture
* '''[http://meego.com/users/poussa Sakari Poussa]''', Core OS Architect, responsible for Core OS architecture
* '''[http://meego.com/users/mythi Mikko Ylinen]''', Handset UX Architect, responsible for Handset UX architecture
* '''[http://meego.com/users/sunilsaxena Sunil Saxena]''', Core OS Architect, responsible for Core OS architecture

== Communication ==

* [http://lists.meego.com/listinfo/meego-architecture MeeGo architecture mailing list]

== Process ==

* Architecture team meets once a week. Currently the meetings are not public.
* Agenda and minutes of the meetings will be posted to the meego-architecture mailing list
* Anyone can propose topics to the architecture team agenda
* Architecture topics can and should be discussed on meego-architecture mailing list
* Architecture team is responsible of making the decision in case consensus is not reached

=== Process Improvement Topics ===

* How to make the architecture meetings open. Not all the topics can be open but most can be. Examples of non-open parts includes topics which involves IPR, legal, patent, business, product or schedule sensitive material.

== Documentation ==

* Developer Documentation: APIs, tutorials, videos, examples ([http://developer.meego.com]), to be published soon
* Architecture Documentation: High level architecture pictures and description ([http://meego.com/developers/meego-architecture])
* Developer and Subsystem Documentation: Detailed technical description of each MeeGo subsystem. Guidelines for developers working on MeeGo. ([[Architecture/Documentation]])

== Meetings ==

* [[Architecture/Meetings]] - Meetings - agenda, minutes

== Upcoming Features ==

MeeGo Bugzilla lists the following features for MeeGo 1.2. The below proposal are all accepted and are on their way to MeeGo 1.2 release.

* Display backlight and keyboard backlight control: [http://bugs.meego.com/show_bug.cgi?id=5525 5525], [http://bugs.meego.com/show_bug.cgi?id=5526 5526], [http://bugs.meego.com/show_bug.cgi?id=5527 5527], [http://bugs.meego.com/show_bug.cgi?id=5528 5528]
** Proposal 1: Maemo 6 MCE
*** ''MCE provides activity monitoring and notifications via D-Bus, controls display and backlight, ALS reading and display tuning, airplane mode''

* Sharing: [http://bugs.meego.com/show_bug.cgi?id=8179 8179], [http://bugs.meego.com/show_bug.cgi?id=8180 8180], [http://bugs.meego.com/show_bug.cgi?id=8181 8181]
** Proposal 1: Maemo6 Sharing framework
*** ''Sharing framework provides a unified API for sharing files via, e.g., BT, email, web services. It includes webupload engine and an API for transfer UI''

* Qt style APIs (that are not covered by Qt Mobility) for display backlight control, alarm/time, heartbeat, system state, thermal
** Proposal 1: Maemo6 QmSystem
*** ''QmSystem provides Qt style public APIs for various system services that are not covered by Qt Mobility''

* Profiles: [http://bugs.meego.com/show_bug.cgi?id=5771 5771], [http://bugs.meego.com/show_bug.cgi?id=5750 5750], [http://bugs.meego.com/show_bug.cgi?id=2889 2889]
** Proposal 1: Maemo6 profiled
*** ''profiled provides a daemon and libraries to access and control profiles related data in the device. The libprofile (C) and libprofile-qt (Qt) are interfaces for the profile client to connect to the server using D-Bus. The profiled data is stored in ‘ini’ files which can be customized per different releases.''

* Ringtones+feedback: [http://bugs.meego.com/show_bug.cgi?id=2889 2889]
** Proposal 1: Maemo6 NGF (non-graphic feedback)
*** ''The device has functionality to alert user of a call, alarms and notification (SMS, email, chat, system update) events. Events may or may not have a graphical part and it may have different behavior depending on the system state. Example of this is receiving an SMS message when there is no other activity and SMS message during a call. NGF provides a unified API for apps to request logical events. The actions (e.g,. play/show LED+audio+vibra) are combined in NGF and consistent look&feel is provided''.

* PIM Storage in Evolution Data Server (EDS) and email via Camel
** architecture decision to move towards EDS and Camel [http://lists.meego.com/pipermail/meego-dev/2011-March/481890.html announced]
** planning [[/planning/evolution-data-server|in progress]]

== Tools ==

Architecture tools

* Architecture navigation tool - able to browse meego packages and visually see the dependencies (coming in Nov)

Mailing list guidelines

2010-10-06T16:13:47Z

Pohly:

==Before You Start==

Please remember that when you are posting to a community mailing list, you are in effect asking a large group of people to give you some of their time and attention - to download your message, read it, and potentially reply to it. It is simply polite to ensure that your message is relevant to as many of the people receiving the message as possible. All of these guidelines stem from this basic principle.

* '''Read the [[Community_communication]] document''': Do not post without reviewing this document.
* '''[[Community_communication#Search_for_existing_answers|Search for existing answers]]''': Believe it or not, your question might not be new - do a [[Community_communication#Search_for_existing_answers|thorough search]] to see if it has been answered before.
* '''Post in the right place''': Review the [[Community_communication]] document and make sure that you are posting in the right place for your topic.

==Posting Guidelines==

===Be Nice===

Be courteous and polite to fellow members in the list:
* Keep the language clean (no swearing)
* Respect other people: No regional, racial, gender or other abuse will be tolerated.

===Keep it Legal===

Make sure that you have the legal right to post your content and are not violating copyright or other laws.

===Keep It Short===

Remember that thousands of copies of your message will exist in mailboxes:
* Keep your messages as short as possible.
* Avoid including log output (select only the most relevant lines, or place the log on a website or in a [http://pastebin.com/ pastebin] instead)
* Don't excessively quote previous messages in the thread (trim the quoted text down to the most recent/relevant messages only).

===Use Proper Posting Style===

* '''No HTML or Rich Text''': Set your mailer to send only plain text messages to avoid getting caught in our spam filters.
* '''Do not top post''': Top posting is replying to a message on "top" of the quoted text of the previous correspondence. This is highly unwanted in mailing lists because it increases the size of the daily digests to be sent out & is highly confusing and incoherent. By default, most email clients top post. Please, remove the irrelevant part of the previous communication(in case of more than a single correspondence) and use bottom, interleaved posting.
* '''Using interleaved posting''': Bottom, interleaved posting is replying to the relevant parts of the previous correspondence just below the block(s) of sentences. For a comment to another block of sentences of the same quoted text, you should move below that relevant block again. Do not reply below the whole of the quoted text. Also remove any irrelevant text.
* '''Use links''': Please provide URLs to articles wherever possible. Avoid cutting and pasting whole articles especially considering the fact that all may not be interested.
* '''Don't include attached files''': Instead of including attached files, please upload your file to the [[Special:Upload|MeeGo wiki]] and post a link to the file from your email message.

===Do Not Hijack Threads ===

Post new questions or new topics as new threads (new email message). Please do not reply to a random thread with a new question or start an unrelated topic of conversation in an existing thread. This creates confusion and makes it much less likely that you will get a response.

===Do Not Cross Post===

Avoid posting to multiple lists simultaneously. Pick a mailing list that is most suitable for your post and just use that. CC'ing multiple lists should be avoided.

===Subscribers Only===

Only subscribers can post to our mailing lists. If you would like to contribute to our mailing lists, we think it is only fair that you be a subscriber. Please note that if you want to participate only occasionally, you can subscribe to a list and set your email options to digest or no mail and read the web archives when you want to catch up. Some of the MeeGo lists are archived on [http://gmane.org/find.php?list=meego gmane.org]. gmane's web and news interface can be used to reply to archived emails without breaking the email thread.

===Recipients===

Always group-reply to an email. Some of the email recipients might not be subscribed, might have turned off email delivery, or read list emails with lower priority than emails addressed to them directly. For the same reasons it is advisable to add relevant people to the recipient list explicitly.

==Guideline Violations==

See our [[Community guidelines|process for dealing with violations]] for more details.

==Requesting a New Mailing List==

Keep in mind that we already have many mailing lists, so new lists need to be justified. Sending a request that has nothing more that "create mailing list x for me" will not be approved without additional justification.

'''Before you request a new list'''
* Review '''all''' of our [[Community_communication#Mailing_Lists_and_Forums|existing mailing lists]]. Is there any way that you can use one of our existing lists to collaborate on your project.
* Think about the upstream lists. Most of the MeeGo components are based on upstream projects. Can you use the upstream infrastructure?

'''How to make the request'''
* Send an email to [[User:Dawnfoster|Dawn Foster]] to request the list.
* Include answers to the following questions in your email.

'''Answer the following questions in the request'''
* Why do you need this list?
* Who will be using this list?
* Who can I name as a co-owner of the list (this should be someone technical who is involved in the day to day working of the project)?
* Why are all of the the [[Community_communication#Mailing_Lists_and_Forums|existing lists]] unsuitable for your project?
* If it relates to an upstream project:
** Is there a reason you need a meego list and aren't using the upstream infrastructure?
** How do you you plan to use this list to contribute back to the upstream project and how will the 2 activities relate to each other?

==Additional Resources==
* [http://www.shakthimaan.com/downloads/glv/presentations/mailing-list-etiquette.pdf Mailing list guidelines by Shakthi Kannan (PDF)]: Great guideline summary and examples of posting styles.

==Acknowledgements==
Credit to the [http://fedoraproject.org/wiki/Communicate/MailingListGuidelines Fedora Mailing List Guidelines] as a starting point under the [http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 Unported] license.

Buteo/SyncFWClient

2010-08-30T06:05:59Z

Pohly:

== Synchronization Framework Client ==

For reference headers, please see [http://meego.gitorious.org/meego-middleware/buteo-syncfw/blobs/master/libsyncfwclient/SyncClientInterface.h SyncClientInterface.h] and [http://meego.gitorious.org/meego-middleware/buteo-syncfw/blobs/master/libsyncprofile/Profile.h Profile.h]

Create a new SyncClientInterface:

sci = new SyncClientInterface();

Connect relevant signals (notification about sync progress and completion):

connect(sci, SIGNAL(syncStatus(QString,int,QString,int)), this, SLOT(slotSyncStatus(QString,int,QString,int)));
connect(sci, SIGNAL(profileChanged(QString,int,Buteo::SyncProfile)), this, SLOT(profileChanged(QString,int,Buteo::SyncProfile)));
connect(sci, SIGNAL(resultsAvailable(QString,Buteo::SyncResults)), this, SLOT(resultsAvailable(QString,Buteo::SyncResults)));
connect(sci, SIGNAL(transferProgress(QString,int,int,QString)), this, SLOT(slotTransferProgress(QString,int,int,QString)));

To load a profile one approach is to use a premade XML-file containing the settings:

QString file = "testsync-scheduleworld.xml";
QString profile = "scheduleworld";
QDomElement root = loadProfileFromXML(file);

Where loadProfileFromXML is implemented as:

QDomDocument doc("profile");
QFile file(fileName);
doc.setContent(&file);
file.close();
QDomElement root = doc.documentElement();
return root;

Create a SyncProfile (which can then be modified to update settings etc):

SyncProfile syncProfile(root);

'''Note that this is not the recommended approach.''' Clients should ask the framework for profiles that were added to the framework. TODO: add example for that part of the API.

Change a setting for the profile:

syncProfile.setKey("Username", “myusername”);
syncProfile.setKey("Password", “mypassword”);

Add the profile, and start the sync:

sci->addProfile(syncProfile);
sci->startSync(profile);

To get a list of the running syncs:

QStringList lst = sci->getRunningSyncList();
qDebug() << "Running syncs:" << lst.length();
for(int i = 0; i < lst.length(); i++) {
qDebug() << "Running" << i << ":" << lst.at(i);
}

== Slots ==

For up to date information regarding the meaning of different status code, see [http://meego.gitorious.org/meego-middleware/buteo-syncfw/blobs/master/libsyncfwclient/SyncClientInterface.h SyncClientInterface.h].

void SyncHandler::slotSyncStatus(QString aProfileId, int aStatus, QString aMessage, int aErrorCode)
{
QString stat = "";
if (aStatus == 0) {
stat = "QUEUED";
} else if (aStatus == 1) {
stat = "RUNNING";
} else if (aStatus == 2) {
stat = "PROGRESSING";
} else if (aStatus == 3) {
stat = "ERROR";
emit syncDone(-3);
} else if (aStatus == 4) {
stat = "DONE";
} else if (aStatus == 5) {
stat = "ABORTED";
}
qDebug() << "STATUS CHANGE:" << aProfileId << stat << aMessage << aErrorCode;
}
void SyncHandler::profileChanged(QString aProfileId, int aChangeType, Buteo::SyncProfile aProfile)
{
qDebug() << "Profile changed:" << aProfileId << aChangeType;
}
void SyncHandler::resultsAvailable(QString aProfileId, Buteo::SyncResults aResults)
{
qDebug() << "Results available" << aProfileId << aResults.resultCode();
if (aResults.resultCode() == Buteo::SyncResults::SYNC_RESULT_SUCCESS) {
// Do something nice when we succeed
} else if (aResults.resultCode() == Buteo::SyncResults::SYNC_RESULT_FAILED) {
// Do something nice when there is a failure
}
}
void SyncHandler::slotTransferProgress(QString aProfileId, int aTransferDatabase, int aTransferType, QString aMimeType)
{
qDebug() << "Progress:" << aProfileId << aTransferDatabase << aTransferType << aMimeType;
}

== Sample XML files for Scheduleworld ==

scheduleworld.com.xml (goes to /etc/sync/profiles/service/):
<?xml version="1.0" encoding="UTF-8"?>
<profile name="scheduleworld" type="service">
<key name="Remote database" value="http://sync.scheduleworld.com/funambol/ds" />

<key name="http_proxy_host" value="" />
<key name="http_proxy_port" value="" />

<key name="destinationtype" value="online"/>

<profile name="syncml" type="client" >
<key name="use_wbxml" value="false" />
<key name="Sync Transport" value="HTTP" />
<key name="Sync Direction" value="two-way" />
<key name="Sync Protocol" value="SyncML12" />
</profile>
<profile name="hcontacts" type="storage" >
<key name="Local URI" value="./contacts" />
<key name="Target URI" value="./card" />
</profile>
</profile>

scheduleworld.xml (goes to /etc/sync/profiles/sync/):

<?xml version="1.0" encoding="UTF-8"?>
<profile name="scheduleworld" type="sync" >
<key name="displayname" value="scheduleworld" />
<key name="enabled" value="true" />
<key name="use_accounts" value="false" />
<key name="hidden" value="false" />
<profile type="service" name="scheduleworld.com" >
</profile>
<profile name="hcontacts" type="storage" >
<key name="enabled" value="true" />
</profile>
</profile>

Buteo/SyncFWClient

2010-08-18T13:07:58Z

Pohly:

== Synchronization Framework Client ==

For reference headers, please see [http://meego.gitorious.org/meego-middleware/buteo-syncfw/blobs/master/libsyncfwclient/SyncClientInterface.h SyncClientInterface.h] and [http://meego.gitorious.org/meego-middleware/buteo-syncfw/blobs/master/libsyncprofile/Profile.h Profile.h]

Create a new SyncClientInterface:

sci = new SyncClientInterface();

Connect relevant signals (notification about sync progress and completion):

connect(sci, SIGNAL(syncStatus(QString,int,QString,int)), this, SLOT(slotSyncStatus(QString,int,QString,int)));
connect(sci, SIGNAL(profileChanged(QString,int,Buteo::SyncProfile)), this, SLOT(profileChanged(QString,int,Buteo::SyncProfile)));
connect(sci, SIGNAL(resultsAvailable(QString,Buteo::SyncResults)), this, SLOT(resultsAvailable(QString,Buteo::SyncResults)));
connect(sci, SIGNAL(transferProgress(QString,int,int,QString)), this, SLOT(slotTransferProgress(QString,int,int,QString)));

To load a profile one approach is to use a premade XML-file containing the settings:

QString file = "testsync-scheduleworld.xml";
QString profile = "scheduleworld";
QDomElement root = loadProfileFromXML(file);

Where loadProfileFromXML is implemented as:

QDomDocument doc("profile");
QFile file(fileName);
doc.setContent(&file);
file.close();
QDomElement root = doc.documentElement();
return root;

Create a SyncProfile (which can then be modified to update settings etc):

SyncProfile syncProfile(root);

'''Note that this is not the recommended approach.''' Clients should ask the framework for profiles that were added to the framework. TODO: add example for that part of the API.

Change a setting for the profile:

syncProfile.setKey("Username", “myusername”);
syncProfile.setKey("Password", “mypassword”);

Add the profile, and start the sync:

sci->addProfile(syncProfile);
sci->startSync(profile);

To get a list of the running syncs:

QStringList lst = sci->getRunningSyncList();
qDebug() << "Running syncs:" << lst.length();
for(int i = 0; i < lst.length(); i++) {
qDebug() << "Running" << i << ":" << lst.at(i);
}

== Slots ==

For up to date information regarding the meaning of different status code, see [http://meego.gitorious.org/meego-middleware/buteo-syncfw/blobs/master/libsyncfwclient/SyncClientInterface.h SyncClientInterface.h].

void SyncHandler::slotSyncStatus(QString aProfileId, int aStatus, QString aMessage, int aErrorCode)
{
QString stat = "";
if (aStatus == 0) {
stat = "QUEUED";
} else if (aStatus == 1) {
stat = "RUNNING";
} else if (aStatus == 2) {
stat = "PROGRESSING";
} else if (aStatus == 3) {
stat = "ERROR";
emit syncDone(-3);
} else if (aStatus == 4) {
stat = "DONE";
} else if (aStatus == 5) {
stat = "ABORTED";
}
qDebug() << "STATUS CHANGE:" << aProfileId << stat << aMessage << aErrorCode;
}
void SyncHandler::profileChanged(QString aProfileId, int aChangeType, Buteo::SyncProfile aProfile)
{
qDebug() << "Profile changed:" << aProfileId << aChangeType;
}
void SyncHandler::resultsAvailable(QString aProfileId, Buteo::SyncResults aResults)
{
qDebug() << "Results available" << aProfileId << aResults.resultCode();
if (aResults.resultCode() == Buteo::SyncResults::SYNC_RESULT_SUCCESS) {
// Do something nice when we succeed
} else if (aResults.resultCode() == Buteo::SyncResults::SYNC_RESULT_FAILED) {
// Do something nice when there is a failure
}
}
void SyncHandler::slotTransferProgress(QString aProfileId, int aTransferDatabase, int aTransferType, QString aMimeType)
{
qDebug() << "Progress:" << aProfileId << aTransferDatabase << aTransferType << aMimeType;
}

== Sample XML files for Scheduleworld ==

scheduleworld.com.xml (goes to /etc/sync/profiles/service/):
<?xml version="1.0" encoding="UTF-8"?>
<profile name="scheduleworld" type="service">
<key name="Remote database" value="http://sync.scheduleworld.com/funambol/ds" />

<key name="Username" value="" />
<key name="Password" value="" />

<key name="http_proxy_host" value="" />
<key name="http_proxy_port" value="" />

<key name="destinationtype" value="online"/>

<profile name="syncml" type="client" >
<key name="use_wbxml" value="false" />
<key name="Sync Transport" value="HTTP" />
<key name="Sync Direction" value="two-way" />
<key name="Sync Protocol" value="SyncML12" />
</profile>
<profile name="hcontacts" type="storage" >
<key name="Local URI" value="./contacts" />
<key name="Target URI" value="./card" />
</profile>
</profile>

scheduleworld.xml (goes to /etc/sync/profiles/sync/):

<?xml version="1.0" encoding="UTF-8"?>
<profile name="scheduleworld" type="sync" >
<key name="displayname" value="scheduleworld" />
<key name="enabled" value="true" />
<key name="use_accounts" value="false" />
<key name="hidden" value="false" />
<profile type="service" name="scheduleworld.com" >
</profile>
<profile name="hcontacts" type="storage" >
<key name="enabled" value="true" />
</profile>
</profile>

Buteo

2010-08-18T12:41:30Z

Pohly:

= Buteo Sync Solution =
The Buteo Sync solution is a complete solution that broadly provides the following synchronization services:
* Device to device synchronization of PIM data (Contacts and Calendar for now) based on SyncML
* Device to cloud synchronization of PIM data (ovi.com, Scheduleworld.com etc.) based on SyncML
* Synchronization of media content to PC based on MTP
* Device to PC synchronization (currently only OviSuite, but this requires contract with OviSuite to support a particular device)

In order to cater to the above service, the following components are available in the Buteo Sync solution:
* Synchronization Framework - a generic framework providing a pluggable architecture. More information [[http://wiki.meego.com/Buteo/Framework here]]
* SyncML stack - a OMA DS 1.1 and 1.2 compliant SyncML stack More information [[http://wiki.meego.com/Buteo/SyncML here]]
* MTP stack - A Media Transfer Protocol 1.0 compliant MTP implemenation. More information [[http://wiki.meego.com/Buteo/MTP here]]
* Sync plugins - a syncml sync plugin and a MTP sync plugin that hook into the synchronization framework

All the above components make up the Buteo Sync solution with the capability of being extended to accommodate more protocols. Refer to the individual pages to understand more about the individual components

= Resources =

To request enhancements or report bugs, please check the [[http://bugs.meego.com/buglist.cgi?type0-1-0=notequals&field0-1-0=product&field0-0-0=component&query_format=advanced&value0-2-0=SyncEvolution&value0-1-0=SyncEvolution&bug_status=NEW&bug_status=NEEDINFO&bug_status=ASSIGNED&bug_status=WAITING%20FOR%20UPSTREAM&bug_status=REOPENED&field0-2-0=component&type0-0-0=substring&value0-0-0=sync&type0-2-0=notequals list of known issues]] and then [[http://bugs.meego.com/enter_bug.cgi?product=OS%20Middleware&component=Buteo%20Sync report new issues]] or [[http://bugs.meego.com/enter_bug.cgi?product=MeeGo%20Core%20OS%20Features&component=Device%20sync propose new features]].

Discussion of Buteo development happens in the issue tracker, on the [[http://lists.meego.com/listinfo/meego-dev Meego Developer list]] and on IRC (freenode.org, #meego-sync).

Source code can be found in the [[http://meego.gitorious.org/meego-middleware Buteo repositories on meego.gitorious.org]].

Buteo

2010-07-14T09:27:53Z

Pohly:

= Buteo Sync Solution =
The Buteo Sync solution is a complete solution that broadly provides the following synchronization services:
* Device to device synchronization of PIM data (Contacts and Calendar for now) based on SyncML
* Device to cloud synchronization of PIM data (ovi.com, Scheduleworld.com etc.) based on SyncML
* Synchronization of media content to PC based on MTP
* Device to PC synchronization (currently only OviSuite, but this requires contract with OviSuite to support a particular device)

In order to cater to the above service, the following components are available in the Buteo Sync solution:
* Synchronization Framework - a generic framework providing a pluggable architecture. More information [[http://wiki.meego.com/Buteo/Framework here]]
* SyncML stack - a OMA DS 1.1 and 1.2 compliant SyncML stack More information [[http://wiki.meego.com/Buteo/SyncML here]]
* MTP stack - A Media Transfer Protocol 1.0 compliant MTP implemenation. More information [[http://wiki.meego.com/Buteo/MTP here]]
* Sync plugins - a syncml sync plugin and a MTP sync plugin that hook into the synchronization framework

All the above components make up the Buteo Sync solution with the capability of being extended to accommodate more protocols. Refer to the individual pages to understand more about the individual components

= Resources =

To request enhancements or report bugs, please check the [[http://bugs.meego.com/buglist.cgi?classification=MeeGo%20Platform&query_format=advanced&bug_status=NEW&bug_status=NEEDINFO&bug_status=ASSIGNED&bug_status=WAITING%20FOR%20UPSTREAM&bug_status=REOPENED&component=Buteo%20Sync&product=OS%20Middleware list of known issues]] and then [[http://bugs.meego.com/enter_bug.cgi?product=OS%20Middleware&component=Buteo%20Sync file new issues]].

Discussion of Buteo development happens in the issue tracker, on the [[http://lists.meego.com/listinfo/meego-dev Meego Developer list]] and on IRC (freenode.org, #meego-sync).

Source code can be found in the [[http://meego.gitorious.org/meego-middleware Buteo repositories on meego.gitorious.org]].

Talk:SDK/Docs/1.0/Building a MeeGo chroot on Linux

2010-06-28T14:04:34Z

Pohly:

Some of the content on this page duplicates the content on [[Hello World - MeeGo x86 development on Linux]].

It would be nice to remove this duplication, but the problem is that the manual Simulator build needs you install packages from within the chroot; while the tarball has the required packages installed already. Finding a way to separate out the chroot explanation has proved difficult as a result.

I've been trying to think of an approach which removes the redundancy, but have not come up with anything reasonable yet. I'll keep trying.

The page uses sdk.download.location in some URLs.

Should that be download3.meego.com?

Who's who

2010-02-19T14:54:04Z

Pohly: /* MeeGo developers */

== Technical Steering Group ==
''Members of the [http://meego.com/about/governance TSG]''

* [http://meego.com/users/imad Imad Sousou/imad] - Benevolent dictator
* [http://meego.com/users/valhalla Valtteri Halla] - Benevolent dictator
* ???

== Maemo community stakeholders ==
'' Official representatives of the Maemo community''

* [http://meego.com/users/qgil Quim Gil/qgil] - Nokia's Maemo Community Manager
* [http://meego.com/users/tekojo Tero Kojo/tekojo] - Nokia's Maemo Technical Project Manager
* [http://meego.com/users/xfade Niels Breet/X-Fade] - maemo.org webmaster
* Dave Neary/dneary - maemo.org docmaster
* [http://meego.com/users/andre André Klapper/andre__] - maemo.org bugmaster
* [http://meego.com/users/jeremiah Jeremiah Foster/jeremiah] - maemo.org debmaster
* [http://meego.com/users/reggie Reggie Suplido] - maemo.org talkmaster
* [http://meego.com/users/stskeeps Carsten Munk/Stskeeps] - maemo.org distmaster & Mer project lead
* [http://meego.com/users/bergie Henri Bergius/bergie] - maemo.org web/Midgard developer
* [http://meego.com/users/vdvsx Valerio Valerio/VDVsx] - Maemo Community Council chair
* [http://meego.com/users/texrat Randall Arnold/Texrat] - Maemo Community Council member
* [http://meego.com/users/qole Alan Bruce/qole] - Maemo Community Council member
* [http://meego.com/users/penguinbait Matthew Lewis/penguinbait] - Maemo Community Council member
* Graham Cobb - Maemo Commnunity Council member

== Moblin community stakeholders ==
''Representatives of the Moblin community''

* [http://meego.com/users/dirkhh Dirk Hohndel/dirkhh] - Chief Linux and open source technologist at Intel
* [http://meego.com/users/townxelliot Elliot Smith/townxelliot] - Moblin.org & meego.com website techy
* [http://meego.com/users/mshaver Michael Shaver/mshaver] - Moblin.org webmaster & meego.com website developer
* [http://meego.com/users/margie Margie Foster/mlfoster] - Localization project manager for Moblin & meego.com website developer

== MeeGo developers ==
'' People paid to contribute to MeeGo and/or have commit rights''

* [http://meego.com/users/nashif Anas Nashif/anaZ] - Random developer
* [http://meego.com/users/auke Auke Kok/auke] - Developer
* [http://meego.com/users/hbons Hylke Bons/hbons] - User Experience Designer
* [http://meego.com/users/jku Jussi Kukkonen/jku] - Developer
* [http://meego.com/users/nmcgovern Neil McGovern/nmcgovern] - Developer
* [http://meego.com/users/pohly Patrick Ohly/pohly] - Developer
* [http://meego.com/users/quang Quang Pham/quang] - Developer

== MeeGo community ==
''Anyone not in the above sections'' (Please keep this list alphabetically-ordered, as it will make finding people easier.)

* [http://meego.com/users/aboaboit Andrea Borgia/aboaboit] - Maemo community member
* [http://meego.com/users/jaffa Andrew Flegg/Jaffa] - Long term gadget freak & Maemo community member
* [http://meego.com/users/lbt David Greaves/lbt] - Mer OBS build guy
* [http://meego.com/users/glezos Dimitris Glezos/glezos] - Localization Engineer ([http://www.transifex.net/ Transifex])
* [http://borasky-research.net M. Edward (Ed) Borasky] - Linux capacity planning / audio / openSUSE / Twitter geek
* [http://meego.com/users/debernardis Ernesto de Bernardis/debernardis] - Maemo community member, mobile device tinkerer
* [http://meego.com/users/fabo Fathi Boudra / fabo] - Debian developer, Maemo community member, software engineer
* [http://meego.com/users/slaine Glen Gray / slaine] - Moblin community member, software engineer
* [http://meego.com/users/dl9pf Jan-Simon Möller / dl9pf ] - Build service developer, Linux Foundation
* [http://meego.com/users/zerojay Jason Carter/zerojay] - Long term Maemo community member
* [http://meego.com/users/lpotter Lorn Potter/lpotter/ljp] - QDF, Mobility, Nokia,
* [http://meego.com/users/martinmohring Martin Mohring / ScriptRipper] - Buildservice developer, Linux Foundation
* [http://meego.com/users/niqt Nicola De FIlippo/niqt] - Qt4 Maemo Contributor, Maemo community member, software engineer
* [http://meego.com/users/rhertzog Raphaël Hertzog / buxy ] - Debian developer, [http://www.freexian.com self-employed] as free software consultant/developer.
* [http://meego.com/users/w00t Robin Burchell/w00t] - Developer of random things, gadget enthusiast, Maemo community member
* [http://meego.com/users/generalantilles Ryan Abel/GeneralAntilles] - Long term Maemo community member
* [http://meego.com/users/slauwers Sebastian Lauwers/crashanddie] - Community member, talk.maemo.org moderator / ActivIdentity Professional Services Technical Consultant
* [http://meego.com/users/timeless timeless/timeless] - Mozilla contributor, Nokia employee.
* [http://meego.com/users/timsamoff Tim Samoff / timsamoff] - Designer (graphic, UI, interaction, web), long-time Maemo Community member (two-term Maemo Community Council Member), and forever open source advocate
* [http://meego.com/users/corsac Yves-Alexis Perez / Corsac] - Debian developer, Maemo community member, security engineer
__NOTOC__ 

[[Category:Community]]