[Opensync-users] Unrelated questions

[Aaron W. <li...@wh...>]

I thought it best to separate these to help those reading in the
archives. For those looking for the original post it is under "Mozilla
Thunderbird Plugin".

> <snip>So to enable opensync to sync passwords you
> would create a plugin that introduces the new object type "Password".
> Then you would introduce the formats used by passwordsafe and eWallet.
> The last thing you would need are the plugins that are capable of
> reading and writing to these 2 storages.
I see, so the creator of the object type would create a new xml format
which was the union of the formats which they expected opensync to
support. How much do the read/write plugins need to do? In the
whitepaper I recall it talking of opening/closing connections, but was
not really sure on the separation here. Is the language of SyncML in one
plugin and the HTTP plugin over which it talks in another (or am I
completely misunderstanding SyncML here)? Connections such as Bluetooth
etc. are handled at the OS level, aren't they?

>>2) I understand that opensync needs to be trained to convert between
>>formats, <snip> but how does opensync compare information in formats
>>when it is not converting? An example of this would be jPilot <snip>

> Jpilot has to do some sort of comparison to see if 2 objects contain
> the same information or if they differ.
> This would also be possible in opensync. Lets assume that we have
> contacts encoded in the format "Palm database". The format plugin
> would then provide a compare() function for this format that would
> tell you if 2 objects are the same (how the compare function does this
> is up to the developer). But the same plugin could also provide
> convert() function

Okay - I didn't realise that so much of the work was done by the plugin
itself. I assumed that the plugin 'taught' opensync to read the format,
gave it a list of what was mapped to what and that opensync did the
actual syncing and merging etc. If it is handled within the plugin it
would make plugins more powerful, but I imagine more prone to being
badly written; Am I correct in thinking that a lazy plugin writer could
omit the difficult merging code and leave the user losing data? From
your answer that seems logical, but that doesn't sit with the merging
posts which I have read about clever systems to write to each device
(regardless of type) and see by trial and error what it can handle.

> I hope this answers your question :)
I think so, thank you :).

>>3) How intelligent is the merging functionality intended to be?

> in this case opensync would merge the changes since none of the
> changes overlap.

As I just asked, will this be a global answer or only if hard-working
people such as yourself write the format plugin ;)?

> This is a very good question. in my opinion we should not try to
> overcome limitations of devices by introducing "hacks". But i guess
> people will try to do this anyways :)

If Opensync wants to consolidate all syncing projects into one, I doubt
that it will have a choice. Otherwise other projects will fill the gap
for specific devices and everyone will lose.

> This problem with recurrences is even more special <snip> Opensync
> would need to be able to detect that this is really a modification of
> another object, update the recurrence rule and write this modified
> object. This would be _VERY_ difficult.

Ergh... that sounds unpleasant. It sounds like another example of
something better written once in some global function than in each
plugin, however. Is that possible?

> The mapping of the custom fields could be done in a different way: The
> configuration of the palm plugin could hold the information on where to
> map the custom fields. This way all userinterface could easily
> implement these options.

Do you mean as mapped against fields in the Opensync xml schema? That
would be a much cleaner way to do things... and would mean that if you
had 6 pairs syncing to Evolution, you would only need to set Evolution
information up once.

> I hope i was able to answer some.

Indeed you were :).

Don't hurry yourself to reply, I would hate to think that I was pulling
people from actually writing the programme in order to answer my silly
questions ;)!

Thanks again for your time,
Aaron