Re: [Opensync-users] Thunderbird plugin

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

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.

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?

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?

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?

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?

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?

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

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