Re: [Opensync-users] Thunderbird plugin

[Armin B. <arm...@de...>]

Aaron Whitehouse wrote:
> Dave Hall wrote:
> 
>>>IANAL, but ...
>>>
>>>The MPL is the only real issue.  The LGPL s3 states:
>>>"3. You may opt to apply the terms of the ordinary GNU General Public
>>>License instead of this License to a given copy of the Library."
>>>
>>>So you have L/GPL you just need to dual license opensync under the MPL.
>>>
>>>Cheers 
>>>Dave
> 
> 
>>Yes, you are right. The MPL license is the only problem since it would
>>be more liberal than the LGPL. But I really don't want to relicense
>>Opensync under the MPL or a similar license. I think the LGPL should
>>be liberal enough (but the opinions differ on this point :)
> 
> 
> I'm sorry but I don't understand what you mean by more liberal. I just
> re-read the MPL and I understand it to be closer to the GPL than the
> LGPL. The MPL does allow code to be released under a 'compatible
> license' - I remember that Cairo was probably fine as LGPL but
> dual-licensed under the MPL to get rid of any question.
> 
> As I see things, the Opensync library is LGPL and could be easily linked
> to by a product covered by the MPL. To me the most straight-forward
> solution would be for Mozilla to write the conduit and release it under
> the MPL; linking to the LGPL libopensync. Please correct me if this idea
> is impossible.
> 

For me it would be fine of course. The question would be if this is ok
for the mozilla developers. I dont have enough knowledge of the MPL to
be able to tell all implications of using LGPL and MPL/LGPL/GPL code nor
do i know how exactly opensync (or a opensync plugin) would be
distributed. Maybe we should discuss this with someone from the mozilla
project.

> I have a couple of unrelated questions:
> 1) As far as I can gather, opensync has categories (To Do, Calender
> etc.) and formats (vcard etc.) - does this mean that a new category
> could be easily accomodated? For example, could opensync be used to
> translate between Passwordsafe and eWallet password programmes? Is the
> opensync xml file category-specific? i.e. Is there one for Calender, one
> for To Dos?
> 

opensync has a concept of object types (what you called categories) and
formats. The object type represent the abstract information like a
contact, a event, a todo, notes, emails etc. The format tells you in
which format this information is currently encoded (like VCARD 2.1 for
contacts).

The knowledge about the formats and object types is capsulated from
opensync by plugins. This allows it to easily extend opensync with new
formats or object types. 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.

The opensync xml format is an internal format used to compare
information that was read in different formats. It is a union of the
supported fields of all other formats so that it can never loose
information. And yes, this is of course object type specific.

> 2) I understand that opensync needs to be trained to convert between
> formats, that the name field in a vCard needs to be mapped to the Name
> in the xml format, but how does opensync compare information in formats
> when it is not converting? An example of this would be jPilot and Palm;
> jPilot uses native palm databases AFAICS and so a format plugin should
> not be necessary to convert between them. But if this is the case, how
> does opensync know enough about the format to sync? Must everything go
> through some translation or do format plugins serve to describe formats
> as well as translate?
> 

I hope i understand your question correctly.

Jpilot has to do some sort of comparison to see if 2 objects contain the
same information or if they differ. Do you mean they do this by directly
comparing the database content?

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
that takes the contact in "Palm database" and converts it to a vcard or
the opensync xml format.

opensync has a path searching algorithm to search for the correct
conversion path from one format to another so you dont have to provide
converters to all other formats.

I hope this answers your question :)

> 3) How intelligent is the merging functionality intended to be? If I
> change the phone number on my phone, the email on my palm and the fax
> number on my PC, will opensync see it as a conflict because the contact
> has changed on both or will it see that each field has only been
> modified once?
> 

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

> 4) How are incomplete implementations of formats handled? If phone uses
> a standard calender format but cannot handle recurrences, will a new
> format plugin need to be written to handle the shortcomings, or would
> workarounds be capable within a 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 :)

This problem with recurrences is even more special since it would mean
that we need to split a single object with recurrences into many objects
without recurrences. The question is what will happen if we delete one
of the objects without recurrence. Opensync would need to be able to
detect that this is really a modification of another object, update the
recurrence rule and write this modifed object. This would be _VERY_
difficult.

> 5) How much interaction is capable with a plugin? Could multisync allow
> a user to map Custom field #1 from the palm with the Birthday field in
> Evolution and those variables carry through as inputs to the format plugin?
> 

basically there is as much interaction possible as you want. The problem
is that every user interface would have to implement a way to use this
interaction so you should be careful about this.

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

> Wow... that was a few more questions than I intended to ask...

I hope i was able to answer some.

> 
> Thanks in advance for your help - I am a big supporter and advocate and
> like to be sure about what I am 'selling'; that and I am too curious for
> my own good ;).
> 
> Aaron