Here is a quick review of the current design and implementation of ERP5SyncML.
Table of Contents
Overall, it is good. However, there are still some inconsistencies or shortcomings, some of which require immediate action.
First of all, let us review the parameters of a publication
Signatures¶ are used to keep a persistent mapping at the publication side between documents on the publication side and documents on the subscription side.p>
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:
- 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
- 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
=> this lines (user = Unre....) are now removed.
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.