Here is a quick review of the current design and implementation of ERP5SyncML. Overall, it is good. However, there are still some inconsistencies or shortcomings, some of which require immediate action.

Publication parameters

First of all, let us review the parameters of a publication

Title

Use Activity

Publication Url

Destination Path

Source URI

Query

XML mapping

Conduit

GPG key name

ID Generator

GID Generator

Media Type

Authentication Format

Authentication Type

Signatures

Signatures are used to keep a persistent mapping at the publication side between documents on the publication side and documents on the subscription side.

Signatures are stored in a persistent mapping (or BTree) based on the GID which derives from their XML content. So, for each GID in synchronisation process, there is one signature. The signature is made of:

In addition, signature keep the following parameters:

Actions (short term)

- Why don't we always use activities ? Either there is a good reason or we should always use them.

Use activity parameter is used by the publication (and subscription too), and make the http response asynchronous. In SyncML recommendation, the publication can't open a new http connection. It's why we use this parameter only to synchronise with other ERP5 instances.

- For more flexibility, it should be possible to define a script to convert common XML into GID rather than expect the conduit to do this (additional parameter).

- Explain how to use GPG keys.

There no documentation and no unit tests on GPG keys, and it not seems to work, so the source code must be checked from the begening and documentation and unit tests must be write.

- I do not understand why the ID generator is needed. Why not rely on newContent ? I would like some explanation. Is it because one may want to control the ID of new objects so that, for example, they are the same on the two sides of a synchronisation ?

Which user is synchronisation processed with ? When I see:

user = UnrestrictedUser('syncml', 'syncml', ['Manager', 'Member'], '')

I feel it is not a standard used, which is a mistake. Please make sure that the whole synchronisation process takes into account user security and does not create a security leak.

=> this lines (user = Unre....) are now removed.

Actions (longer term)

Is it possible to use a path to identify objects on the publication side rather than an ID. This would make it possible to synchronise objects stored in different modules. If not, the use of uids is probably the best way. Is this compatible with SyncML (uids are long ints). Generally speaking, the combination of destination path + object_id to represent documents on the publication side is too restrictive and should be improved.

Make sure queries can return a list of brains (not objects).

Explain how to use email for synchronisation.

How should relations be synchronised between 2 ERP5 sites.

Discussion/SyncMLDesign (last edited 2008-01-03 13:48:09 by localhost)