opensync-devel — The place to coordinate the development of OpenSync

Re: [Opensync-devel] libwbxml 0.10.9

[Emanoil K. <del...@ya...>]

Hi

> 
> In particular, if Android creates vCard/vCalendar files in
> UTF-16 then GPE  
> won't import them by default (and neither will anything
> else, I guess!).
> 
> Graham
> 

what I wanted to point out is that developers often do not understand/implement conversions (in the right place). Especially linux moved very slowly towards UTF and it's still causing problems.

My apeal is for a general solution - or I simply wanted to say watch out.
Especially gnome (I can not argue for the recent versions) had poor support in conversion, resulting very often in double converting char data.

any way this was just a note. if the thing you are working on is using exerces (the reason for utf-16) you should call internal functions to get strings formatted for your current machine.

regards




      

Re: [Opensync-devel] [Opensync-users] libwbxml 0.10.9

[Michael B. <mic...@cm...>]

On 01/10/11 12:32, Emanoil Kotsev wrote:
> 
>> The handling of the character set must be fixed because of some 
>> requirements of Android. They use UTF-16 without a default 
>> encoding. This is legal according to the specification but
>> requires that the character set is specified by the transport. This
>> is actually not possible with libwbxml.
> 
> From my work with xerces it is not bad idea to use utf-16. In some
> cases it has more advantages as disadvantages. Why is it not possible
> to set a default charset in libwbxml. Why should one need anything
> else except utf?

The problem is that the specification does not define one default
encoding. The old specifications WBXML 1.0 or so defined UTF-8 but the
new specification WBXML 1.3 defines UTF-8 and UTF-16.

So if there is no character set specified which character set should be
used? libwbxml uses UTF-8 as default because this is compliant with new
and old versions of the specification.

Android uses UTF-16 and does not specify the character set in the WBXML
document. So the user of the library must set the character set via the
interface.

Best regards

Michael
-- 
___________________________________________________________________

Michael Bell                        Humboldt-Universitaet zu Berlin

Tel.: +49 (0)30-2093 70143          ZE Computer- und Medienservice
Fax:  +49 (0)30-2093 70135          Unter den Linden 6
mic...@cm...       D-10099 Berlin
___________________________________________________________________

PGP Fingerprint: 09E4 3D29 4156 2774 0F2C  C643 D8BD 1918 2030 5AAB

Re: [Opensync-devel] libwbxml 0.10.9

[Graham C. <g+o...@co...>]

On Monday 10 January 2011 11:50:55 Emanoil Kotsev wrote:
> --- On Mon, 1/10/11, Graham Cobb <g+o...@co...> wrote:
> > From: Graham Cobb <g+o...@co...>
> > Nothing to do with OpenSync... Does anyone know if Android
> > has a facility to
> > export vCard/vCalendar files?  And, if so, whether
> > those are in UTF-16 as well?
> 
> I do not agree fully here with you. OpenSync has a general problem with
> charsets as visible from the tickets I've opened recently. And if I would
> do some more testing I would open more tickets on this subject.

Thanks for your reply, Emanoil.  Of course, you are right that OpenSync has 
similar problems.  But I probably did not make myself completely clear: I was 
trying to use the experience of people on the list to get help with a different 
project: I maintain the import/export code for GPE and I hoped that there were 
people on the list who could tell me how Android creates exported files so I 
can add logic to the GPE import code to handle them.

In particular, if Android creates vCard/vCalendar files in UTF-16 then GPE  
won't import them by default (and neither will anything else, I guess!).

Graham

Re: [Opensync-devel] libwbxml 0.10.9

[Emanoil K. <del...@ya...>]

Hi, Graham,

--- On Mon, 1/10/11, Graham Cobb <g+o...@co...> wrote:

> From: Graham Cobb <g+o...@co...>

> Michael Bell wrote:
> > The handling of the character set must be fixed
> because of some
> > requirements of Android. They use UTF-16 without a
> default encoding.
> 
> Nothing to do with OpenSync... Does anyone know if Android
> has a facility to 
> export vCard/vCalendar files?  And, if so, whether
> those are in UTF-16 as well?

I do not agree fully here with you. OpenSync has a general problem with charsets as visible from the tickets I've opened recently. And if I would do some more testing I would open more tickets on this subject.

> 
> If so, I would like to make sure they can be imported into
> GPE (this is direct 
> import of the file, not using OpenSync).  There is an
> analogous problem as the 
> RFC's do not specify charsets (requiring that the
> containing transport 
> specifies the charset) -- but when passing text files
> around, there is no way to 
> specify the charset.  So GPE applies a heuristic to
> guess!

you can use any type of convertor/editor to get the desired results ;-)

> 
> If anyone could send me a vCard and/or vCalendar file
> exported by Android (and 
> containing non-ASCII characters, for example in names or
> addresses) it would 
> be appreciated.
> 

unfortunately I have only symbian and older phones and can not speak for android.

I have noticed something strange in this conjunction. On the phone I can not use i.e. cyryllic or greek input chars (the phone is with german setup - nokia 5530), but I can sync data written in cyrillic (UTF-8) with the phone. Unfortunately I have no successfull test with opensync 0.40 so far 

Another issue (also not libwbxml) related (as I reported earlier libwbxml seem to be working fine for contacts and calendar incl. todo and notes) is that some fields are in quted printable or base64 encoded, which breaks OpenSync (merge/sync etc) and I have a mess up with contacts having such data - I think I have opened tickets realted to this in opensync.

regards



      

Re: [Opensync-devel] [Opensync-users] libwbxml 0.10.9

[Emanoil K. <del...@ya...>]

> The handling of the character set must be fixed because of
> some
> requirements of Android. They use UTF-16 without a default
> encoding.
> This is legal according to the specification but requires
> that the
> character set is specified by the transport. This is
> actually not
> possible with libwbxml.

>From my work with xerces it is not bad idea to use utf-16. In some cases it has more advantages as disadvantages. Why is it not possible to set a default charset in libwbxml. Why should one need anything else except utf?

regards


      

Re: [Opensync-devel] libwbxml 0.10.9

[Graham C. <g+o...@co...>]

On Monday 10 January 2011 07:21:37 Michael Bell wrote:
> The handling of the character set must be fixed because of some
> requirements of Android. They use UTF-16 without a default encoding.

Nothing to do with OpenSync... Does anyone know if Android has a facility to 
export vCard/vCalendar files?  And, if so, whether those are in UTF-16 as well?

If so, I would like to make sure they can be imported into GPE (this is direct 
import of the file, not using OpenSync).  There is an analogous problem as the 
RFC's do not specify charsets (requiring that the containing transport 
specifies the charset) -- but when passing text files around, there is no way to 
specify the charset.  So GPE applies a heuristic to guess!

If anyone could send me a vCard and/or vCalendar file exported by Android (and 
containing non-ASCII characters, for example in names or addresses) it would 
be appreciated.

Graham

Re: [Opensync-devel] [Opensync-users] libwbxml 0.10.9

[Michael B. <mic...@cm...>]

On 01/08/11 19:59, Emanoil Kotsev wrote:
> 
> --- On Sat, 1/8/11, Michael Bell <mic...@cm...> wrote:
>>
>> libwbxml 0.10.9 release notes
> 
> What about the svn version as this is what I'm having currently installed?

The SVN trunk version is at the moment exactly the same as libwbxml
0.10.9. The next step is to create branch/libwbxml-0.10.x. After this I
will add the changes which break the binary compatibility.

The handling of the character set must be fixed because of some
requirements of Android. They use UTF-16 without a default encoding.
This is legal according to the specification but requires that the
character set is specified by the transport. This is actually not
possible with libwbxml.

Additionally I will fix the element names of the Microsoft ActiveSync
WBXML table.

I will change the SO-naming before I break the binary compatibility. So
your local installation should not be damaged by SVN checkouts.

Best regards

Michael
-- 
___________________________________________________________________

Michael Bell                        Humboldt-Universitaet zu Berlin

Tel.: +49 (0)30-2093 70143          ZE Computer- und Medienservice
Fax:  +49 (0)30-2093 70135          Unter den Linden 6
mic...@cm...       D-10099 Berlin
___________________________________________________________________

PGP Fingerprint: 09E4 3D29 4156 2774 0F2C  C643 D8BD 1918 2030 5AAB

Re: [Opensync-devel] libsynthesis and vformats

[Chris F. <cd...@fo...>]

On Sun, Jan 09, 2011 at 05:58:42PM +0100, Lukas Zeller wrote:
> But maybe the point is something different - as much as I agree with
> the goals of free software, I'm not so sure about the total insurance
> attitute that sometimes accompanies it. I mean, if the current licensing
> terms are a problem for someone who would like to actually *do* something,
> please let me know. But expecting from me to risk 10 (full time!) years
> first, so that maybe eventually somebody could feel more inclined to
> considering contributing with zero risk... Not really.

My original email in this thread was meant to let you know. :-)

To me, a contributor agreement, of any kind, says to the community that
the LGPL is good enough for them, but not good enough for the author.
Basically, it is a big sign saying that the author wants to work alone.

For example, I never dreamed of contributing to MySQL, even though I
used the free version regularly.  About the most I might have done was
report a bug.  I only did that once in an area that affected me, but I
didn't bother working up a patch.  The contributor agreement / closed
nature of MySQL was a real factor in deciding not to pursue writing a
patch.

And personally, this goes for the FSF as well.  I'm a bit more odd in
that case, though.

There's only so much time in the day, and sometimes seemingly small
issues like licenses and paperwork or lack of trust sway the balance
in certain directions.  And sometimes money sways it in the other.

Of course, there are business reasons why the dual license / contributor
agreement path is taken, and if actual money is being made, hey, that
works.  And in some cases the suits force these decisions on the programmers
too.  But the money is instead of contributions.  For some, that
tradeoff is well worth it, and I acknowledge that.

- Chris

Re: [Opensync-devel] libsynthesis and vformats

[Chris F. <cd...@fo...>]

On Sun, Jan 09, 2011 at 03:42:54PM +0100, Lukas Zeller wrote:
> On Jan 8, 2011, at 15:33 , Michael Banck wrote:
> > In any case, having it LGPL should make it possible to develop and sell
> > proprietary products on top of libsynthesis, as long as you don't need
> > to modify libsynthesis itself for it.
> 
> Except that for iOS, which happens to be the source of funding for
> my work on libsynthesis, that does not work, because iOS apps need
> to be statically linked with all libraries (except those provided by
> the system).

It is my understanding that LGPL libraries can be linked statically
to closed source applications, as long as all the object files of the
closed source app are provided along with the LGPL library, so that
the recipient can re-link to a modified LGPL library.

Other library licenses may be blocking this, but not the LGPL.

- Chris

Re: [Opensync-devel] libsynthesis and vformats

[Lukas Z. <lu...@pl...>]

Hi Michael,

On Jan 9, 2011, at 16:03 , Michael Banck wrote:

>> True, but quite a big risk to take. I've invested 10 years into this
>> and didn't get a single penny funding except for selling products
>> based on this code, in a narrow niche.
> 
> I am not saying you would get funding, I am just saying you could still
> sell your products that way, and have the code open to everybody.  Of
> course, nobody can guarantee you that you would get more external
> contributors if you did so, but libsynthesis would certainly be more
> interesting to contribute to.

No doubt. But if my business, which has alone funded all of libsynthesis, goes down the drain in the process, that wouln't help the project much.

I'm not saying that I disagree with you on the goal to make software open, but I'm saying that there's risk involved. None of the less strict licenses than GPL would exist at all if there wasn't always the problem of how to fund the developer's lives somehow. I big companies, that's going around many corners and thus is not always so obvious, but I'm facing a pretty bare-bone situation here. Make basic income happen anytime soon, and things would look different :-)

>>> 2. Relicense the code to say "LGPL 2.1 or later".  That would remove
>>> potential concerns that in the future libsynthesis will be incompatible
>>> with LGPLv4 libraries, if a new version of the LGPL gets released ever.
>> 
>> Worth considering, sure, but it does not solve the problem that we
>> still need a contributor agreement.
> 
> Right, but maybe some people would be more willing to sign it.

Maybe.

But maybe the point is something different - as much as I agree with the goals of free software, I'm not so sure about the total insurance attitute that sometimes accompanies it. I mean, if the current licensing terms are a problem for someone who would like to actually *do* something, please let me know. But expecting from me to risk 10 (full time!) years first, so that maybe eventually somebody could feel more inclined to considering contributing with zero risk... Not really.

>> Our CA is a almost 1:1 copy of the SCA (Sun, for OpenOffice), and
>> states that "Any contribution we make available under any license will
>> also be made available under a suitable FSF (Free Software Foundation)
>> or OSI (Open Source Initiative) approved license".
> 
> Well, the SCA certainly doesn't have the best image.  However, that is
> mostly due to the potential to take code (partly) proprietary.  You
> already did that,

Not quite - we just couldn't risk making all our code OS without commercially risking our heads and in consequence the entire project. So we had to find ways to *keep* part of the code proprietary, and in particular work around the incompatibility of LGPL and iOS static linking requirements. That's something quite different from *taking* code proprietary.

> so that is probably clear to prospective contributors.
> 
> I see how it would be difficult to get outside contributions that way.

You might be right - but then I haven't had a single complaint from anyone who actually wanted to contribute and found the terms were restricting.

The current licensing model and contributor agreement is a result of active communication and negotiation between actively interested parties, and so will be future changes thereof.

Lukas

Re: [Opensync-devel] libsynthesis and vformats

[Michael B. <mb...@de...>]

Hi,

On Sun, Jan 09, 2011 at 03:42:54PM +0100, Lukas Zeller wrote:
> On Jan 8, 2011, at 15:33 , Michael Banck wrote:
> > There's a couple of things you could do (or maybe you did already, I did
> > not check your contributor agreement) to make libsynthesis more
> > appealing to external developers:
> > 
> > 1. You could relicense it to BSD.  That would allow you to use your
> > modified version of the code (plus any external future contributions) in
> > proprietary products.  Of course, it would allow the same to possible
> > competitors, not sure you have any.  In that case, you could drop the
> > contributor agreement.
> 
> True, but quite a big risk to take. I've invested 10 years into this
> and didn't get a single penny funding except for selling products
> based on this code, in a narrow niche.
 
I am not saying you would get funding, I am just saying you could still
sell your products that way, and have the code open to everybody.  Of
course, nobody can guarantee you that you would get more external
contributors if you did so, but libsynthesis would certainly be more
interesting to contribute to.

> > 2. Relicense the code to say "LGPL 2.1 or later".  That would remove
> > potential concerns that in the future libsynthesis will be incompatible
> > with LGPLv4 libraries, if a new version of the LGPL gets released ever.
> 
> Worth considering, sure, but it does not solve the problem that we
> still need a contributor agreement.

Right, but maybe some people would be more willing to sign it.
 
> > 2. If not already the case, you could modify the contributor agreement
> > to guarantee the free software community that the public version of the
> > code will always be in the spirit of the LGPL as published by the Free
> > Software Foundation.
> 
> Our CA is a almost 1:1 copy of the SCA (Sun, for OpenOffice), and
> states that "Any contribution we make available under any license will
> also be made available under a suitable FSF (Free Software Foundation)
> or OSI (Open Source Initiative) approved license".

Well, the SCA certainly doesn't have the best image.  However, that is
mostly due to the potential to take code (partly) proprietary.  You
already did that, so that is probably clear to prospective contributors.

I see how it would be difficult to get outside contributions that way.


Michael

Re: [Opensync-devel] libsynthesis and vformats

[Lukas Z. <lu...@pl...>]

Hello Michael,

On Jan 8, 2011, at 15:33 , Michael Banck wrote:

>> The thing is, there's simply no money except our own (2 people)
>> funding our work in libsynthesis, so we need the closed derived work
>> (products we sell) to keep it going. 
> 
> AFAICT, the public part of libsynthesis is LGPL, right?  Does it have an
> "or later" clause for the versioning of the license?

Presently it is dual licensed under LGPL 2.1 and 3.0

> In any case, having it LGPL should make it possible to develop and sell
> proprietary products on top of libsynthesis, as long as you don't need
> to modify libsynthesis itself for it.

Except that for iOS, which happens to be the source of funding for my work on libsynthesis, that does not work, because iOS apps need to be statically linked with all libraries (except those provided by the system).

>> That's why we have the contributor agreement. Without it, we cannot
>> use contributions to libsynthesis ourselves which would essentially
>> split the project into a internal and a public version. We'll not do
>> that with the version we provide the infastructure for, but of course
>> anyone who feels too much restrained by a contributor agreement could
>> start maintaining a separate fork.
> 
> There's a couple of things you could do (or maybe you did already, I did
> not check your contributor agreement) to make libsynthesis more
> appealing to external developers:
> 
> 1. You could relicense it to BSD.  That would allow you to use your
> modified version of the code (plus any external future contributions) in
> proprietary products.  Of course, it would allow the same to possible
> competitors, not sure you have any.  In that case, you could drop the
> contributor agreement.

True, but quite a big risk to take. I've invested 10 years into this and didn't get a single penny funding except for selling products based on this code, in a narrow niche.

> 2. Relicense the code to say "LGPL 2.1 or later".  That would remove
> potential concerns that in the future libsynthesis will be incompatible
> with LGPLv4 libraries, if a new version of the LGPL gets released ever.

Worth considering, sure, but it does not solve the problem that we still need a contributor agreement.

> 2. If not already the case, you could modify the contributor agreement
> to guarantee the free software community that the public version of the
> code will always be in the spirit of the LGPL as published by the Free
> Software Foundation.

Our CA is a almost 1:1 copy of the SCA (Sun, for OpenOffice), and states that "Any contribution we make available under any license will also be made available under a suitable FSF (Free Software Foundation) or OSI (Open Source Initiative) approved license".

Best Regards,

Lukas Zeller

Re: [Opensync-devel] OpenSync priorities

[Quentin D. <que...@gm...>]

Thank you Emanoil for this good summary. I am in fact very busy right now, but 
I want to let you know that I approve the mentioned points.

In the hope that this will have a positive outcome, kind regards!


On Saturday 08 January 2011 21:30:44 Emanoil Kotsev wrote:
> Hello,
> 
> Appart the plans for the future I think there is small effort needed to
> make  the last step to a successfull sync with a phone over syncml and the
> current svn version of libopensync (0.40).
> 
> I still can not believe that no one is using this framework for syncing
> with real phones.
> 
> As I understood from Quentin he is busy ATM, so I want to sum up the
> current blocking issues and goals that we both think have a short term
> priority.
> 
> I. Suggestions on high priority issues in the present
> 
> First of all somebody has to put some effort into libsyncml and help
> Michael - if possible becoming his substitute and take over. I guess there
> is just a little bit needed to have positive results, but this goes beyond
> my goals and capabilities ATM and the desire Michael has to leave.
> 
> Alternativ make plans to start libsynthesis plugin (it will take longer,
> but could be more beneficient).
> 
> In both cases you need a dedicated person with long time plans to work in
> the area (syncml)
> 
> Second, reorganise responsibilities for the future release and be ready to
> answer/fix user problems. With the current speed it does not make any
> sense to discuss whatever we are discussing here. Also document your own
> code and work on documenting the engine. I'm amased how good the akonadi
> documentation is.
> 
> Third, do whatever needed to get a release in short terms. From my tests I
> think a compromise could be done easier i.e. if users are recommended to
> use different configurations for different obj-types, so that the slow
> sync issue could have less impact. I personally would accept such a deal,
> given the promise to fix it in future. The rest was discussed before.
> 
> This issue is very nasty and I don't know what's necessary to have it
> fixed, but it needs to be done for a stable release - with no doubt.
> Fortunately it does not happen every time - so may be a workaround could
> be enough.
> 
> 
> II. Issues open and blocking my investigations/tests with kde
> (opensync/akonadi) and nokia 5530 (opensync/syncml)
> 
> 1. libsyncml
> 
> 1.a https://libsyncml.opensync.org/ticket/272#comment:1
>  this is libsyncml (as I mentioned before libwbxml seems to be working -
> tested with contact and calendar data)
> 
> 1.b https://libsyncml.opensync.org/ticket/273
>     https://libsyncml.opensync.org/ticket/274
> 
>  unknown alert type 255 breaks normal sync so the only option is slow-sync
> 
> 1.c syncml-client/server could be better for current phones (but I'm not
> sure if this conclusion is true) also the code seems not to be clean and
> funcitonal at 100%
> 
> 
> 2. libopensync
> 
>  http://www.opensync.org/ticket/1442
>  http://www.opensync.org/ticket/1444 - a problem in the parser (converter)
> breaks sync of contact data
> 
> Could we discuss in short terms how to solve these issues please!
> 
> I'm willing to have a succcessfull sync with my phone soon and I'm sure if
> it works for me it will work for every one with a symbian nokia phone.
> 
> Kind regards in advance

[Opensync-devel] OpenSync priorities

[Emanoil K. <del...@ya...>]

Hello,

Appart the plans for the future I think there is small effort needed to make  the last step to a successfull sync with a phone over syncml and the current svn version of libopensync (0.40).

I still can not believe that no one is using this framework for syncing with real phones.

As I understood from Quentin he is busy ATM, so I want to sum up the current blocking issues and goals that we both think have a short term priority.

I. Suggestions on high priority issues in the present

First of all somebody has to put some effort into libsyncml and help Michael - if possible becoming his substitute and take over. I guess there is just a little bit needed to have positive results, but this goes beyond my goals and capabilities ATM and the desire Michael has to leave.

Alternativ make plans to start libsynthesis plugin (it will take longer, but could be more beneficient).

In both cases you need a dedicated person with long time plans to work in the area (syncml)

Second, reorganise responsibilities for the future release and be ready to answer/fix user problems. With the current speed it does not make any sense to discuss whatever we are discussing here.
Also document your own code and work on documenting the engine. I'm amased how good the akonadi documentation is.

Third, do whatever needed to get a release in short terms. From my tests I think a compromise could be done easier i.e. if users are recommended to use different configurations for different obj-types, so that the slow sync issue could have less impact. I personally would accept such a deal, given the promise to fix it in future. The rest was discussed before.

This issue is very nasty and I don't know what's necessary to have it fixed, but it needs to be done for a stable release - with no doubt. Fortunately it does not happen every time - so may be a workaround could be enough.


II. Issues open and blocking my investigations/tests with kde (opensync/akonadi) and nokia 5530 (opensync/syncml)

1. libsyncml

1.a https://libsyncml.opensync.org/ticket/272#comment:1
 this is libsyncml (as I mentioned before libwbxml seems to be working - tested with contact and calendar data)

1.b https://libsyncml.opensync.org/ticket/273
    https://libsyncml.opensync.org/ticket/274

 unknown alert type 255 breaks normal sync so the only option is slow-sync

1.c syncml-client/server could be better for current phones (but I'm not sure if this conclusion is true) also the code seems not to be clean and funcitonal at 100%


2. libopensync 

 http://www.opensync.org/ticket/1442
 http://www.opensync.org/ticket/1444 - a problem in the parser (converter) breaks sync of contact data

Could we discuss in short terms how to solve these issues please!

I'm willing to have a succcessfull sync with my phone soon and I'm sure if it works for me it will work for every one with a symbian nokia phone.

Kind regards in advance



      

Re: [Opensync-devel] [Opensync-users] libwbxml 0.10.9

[Emanoil K. <del...@ya...>]

--- On Sat, 1/8/11, Michael Bell <mic...@cm...> wrote:

> From: Michael Bell <mic...@cm...>
> Subject: [Opensync-users] libwbxml 0.10.9
> 
> libwbxml 0.10.9 release notes
> 

What about the svn version as this is what I'm having currently installed?

regards


      

Re: [Opensync-devel] hash of a change

[deloptes <del...@ya...>]

deloptes wrote:

> Do you know if hash = 0 has some special meaning in the hashtable/get
> change type?

can someone answer this question pls?

> 
> I keep getting different sets of add/modify changes when saying N to
> Synchronization Forecast Summary
> 
> I'm not sure why. Either wrong report/update, not unreffed changes or
> there is something I don't understand
> 


I know now that this is because of slow syncing, but an one confirm?

thanks

Re: [Opensync-devel] akonadi-sync phase 2

[deloptes <del...@ya...>]

deloptes wrote:

> Hi,
> 
> for pity I've found out that the current solution works for contacts very
> well, but for the other types and particularly when using more then one it
> is producing errors. Especially after rejecting a forecast.
> 
> I'm trying to find out why and I thing it is context related, but first of
> all I'm not sure where I have to set userdata (
> osync_objtype_sink_set_userdata ( sink, this ); ) in the syncbase class or
> in the derived classes? Or it doesn't matter. the second question is how
> it is supposed to set context info and sink. Can someone with more
> programming experience give me a hint. After thinking a lot in he past
> days I think it is correct to put it in the base class and not as it is
> now - in the derived classes.
> 
> the second question is in general about how ctx,info etc are passed to the
> subclass - dereferencing. where should it take place? I've added also
> sb->setSink(sink); to the WRAP makro and the function in the manner of 
> the rest
> 
> #define WRAP() \
>   osync_trace( TRACE_ENTRY, "%s(%p,%p, %p, %p)", __PRETTY_FUNCTION__,
>   sink,
> info, ctx, userdata); \
>   SinkBase *sb = reinterpret_cast<SinkBase*>(userdata); \
>   sb->setSink(sink);\
>   sb->setPluginInfo( info );\
>   sb->setContext( ctx );
> 
> ...
> 
> void SinkBase::setSink(OSyncObjTypeSink *sink)
> {
>     Q_ASSERT( mSink == 0 || sink == mSink );
>     mSink = sink;
> }
> 


For the record this was also fixed, though no one really answered here.

regards

Re: [Opensync-devel] akonadi-sync todos

[deloptes <del...@ya...>]

deloptes wrote:

> hi, everybody,
> 
> the good news. akonadi-sync improved and few fixes were applied, so now
> syncing with contacts and events is almost perfect. However I have two
> questions:
> 
> 1) is note vs. contact a reserved word in <ObjType>contact</ObjType>. I
> think I remeber I have read that few objtypes are supported ... but where?
> 
> I have event/todo/journal as members of calendar and notes as different
> type in kde. This is still the same discussion as before. notes are not
> journal notes or are they? I'm a bit lost here
> 
> 2) I'm not sure why I get often errors while working on todo in the xml
> part
> of opensync. I actually managed to sync once or twice todos,  but still
> from time to time there are errors as shown below. If some one has
> experience it would be highly appreciated to give me advice.
> To me it looks like 'AlarmDisplay' is not supported by xsd.
> 

For the record all of those questions/issues were fixed!

Re: [Opensync-devel] Gnokii patch

[deloptes <del...@ya...>]

Emanoil Kotsev wrote:

> Hi, I could do the check in and have a look into the plugin.
> I prefer c++ but in C were the first lesson in serious programming that I
> had back in 1990 ...
> 
> If you are familiar with object oriented programming (I think you are) and
> C++ think of C as if objects (C++) are structures (C) and methods (C++)
> are loose functions (C) so that everything in C is a function besides
> structures and variables. I hope this brief info helps you understand it.
> 
> Thank you for looking for alternatives I was wondering what this gnkokii
> thing was all about.


sorry I couldn't apply the patch

Username: deloptes
Password for 'deloptes':
Sending        src/gnokii_calendar_format.c
svn: Commit failed (details follow):
svn: Server sent unexpected return value (403 Forbidden) in response to
CHECKOUT request
for '/!svn/ver/5638/plugins/gnokii-sync/src/gnokii_calendar_format.c'
svn: Your commit message was left in a temporary file:
svn:    '/home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/svn-commit.3.tmp'

I was thinking one could commit in any plugin

regards

[Opensync-devel] libwbxml 0.10.9

[Michael B. <mic...@cm...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

libwbxml 0.10.9 release notes

Download: https://sourceforge.net/projects/libwbxml/files/libwbxml/0.10.9/

Major Changes
=============

  - This is the last 0.10.x release.
  - This is the last release of libsyncml.so.0.
  - The next release will break the API because of a bug in the handling
    of the charcter set. The library must support a default character
    set which can be specified in the transport meta information.

Minor Changes
=============

  - Added correct default behaviour to parse_charset. If no character
    set is specified in a WBXML document then UTF-8 is assumed until
    there is another specification in the transport meta-information.
    (ticket #52)
  - Added several tokens for Microsoft ActiveSync v14.0 revision 8.0
    (ticket #53). The patch was supplied by Amnon Aaronsohn.
  - Fixed iconv support (ticket #52)
  - Fixed wrong WBXML table token for OMA DM DDF (ticket #51)
  - Fixed locations of variable definitions and replaced strtoull by
    strtoul (changes from ticket #42 and #50).
    This fixes some compiler errors from MS VisualStudio 2008 and 9.0.

Internal Changes
================

  - Fixed integer overflow in opaque data parsing (ticket #54).
    The patch was supplied by Amnon Aaronsohn.
  - Fixed unsigned integer overflow (patch from ticket #41)
    The overflow causes crashs or wrong wbxml messages.
  - Added support for recursion in wbxml_tree_node_elt_get_from_name
    (ticket #46)

Special thanks goes to Amnon Aaronsohn who provided an update for the
Microsoft Active Sync support.

Best regards

Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk0omJcACgkQ2L0ZGCAwWqs0xgCgunG+ZXSHrQIn7FuyFNuVglDW
ytsAoOJd5zYTBI6HKmCviupneI2Zg/LN
=Q3w/
-----END PGP SIGNATURE-----

Re: [Opensync-devel] libsynthesis and vformats

[deloptes <del...@ya...>]

Michael Banck wrote:

> On Sat, Jan 08, 2011 at 05:12:40AM -0800, Emanoil Kotsev wrote:
>> > Are you interested in any help with this that does not involve
>> > signing a contributor agreement?
>> > 
>> 
>> Licensing of synthesis was also my consideration. Interesting to know
>> how Patrick has solved it into his project. I don't remember if I had
>> to sign a license agreement when running syncevo the first time
> 
> Chris was talking about contributor agreements, not license agreements.
> It is about when you donate code to the project, they want you to sign
> over some parts of your copyright so they can potentially relicense the
> code to their liking (either to another open source license, or
> dual-license it with a proprietary license for their clients).  This
> does not affect users of the software.
> 
> 

thanks I just understood this later :-)

Re: [Opensync-devel] libsynthesis and vformats

[Michael B. <mb...@de...>]

On Sat, Jan 08, 2011 at 02:38:17PM +0100, Lukas Zeller wrote:
> Hello Chris,
> 
> On Jan 7, 2011, at 22:04 , Chris Frey wrote:
> 
> > I notice that there seems to be a difference in development and licensing
> > strategies between OpenSync and libsynthesis.  Anyone can contribute
> > to OpenSync and not have to sign anything, while it appears that
> > contributing to libsynthesis requires signing a contributor agreement.
> > This is off-putting to some developers.
> 
> The thing is, there's simply no money except our own (2 people)
> funding our work in libsynthesis, so we need the closed derived work
> (products we sell) to keep it going. 

AFAICT, the public part of libsynthesis is LGPL, right?  Does it have an
"or later" clause for the versioning of the license?

In any case, having it LGPL should make it possible to develop and sell
proprietary products on top of libsynthesis, as long as you don't need
to modify libsynthesis itself for it.

> That's why we have the contributor agreement. Without it, we cannot
> use contributions to libsynthesis ourselves which would essentially
> split the project into a internal and a public version. We'll not do
> that with the version we provide the infastructure for, but of course
> anyone who feels too much restrained by a contributor agreement could
> start maintaining a separate fork.

There's a couple of things you could do (or maybe you did already, I did
not check your contributor agreement) to make libsynthesis more
appealing to external developers:

1. You could relicense it to BSD.  That would allow you to use your
modified version of the code (plus any external future contributions) in
proprietary products.  Of course, it would allow the same to possible
competitors, not sure you have any.  In that case, you could drop the
contributor agreement.

2. Relicense the code to say "LGPL 2.1 or later".  That would remove
potential concerns that in the future libsynthesis will be incompatible
with LGPLv4 libraries, if a new version of the LGPL gets released ever.

2. If not already the case, you could modify the contributor agreement
to guarantee the free software community that the public version of the
code will always be in the spirit of the LGPL as published by the Free
Software Foundation.  This is how the FSF contributor agreement works
(except it also guarantess the FSF will not sell proprietary versions
either, I think).  That will remove potential concerns that you might
relicense the code to GPL or some other, possibly incompatible license
to whatever the contributor uses themselves to interact with
libsynthesis.


Michael

Re: [Opensync-devel] libsynthesis and vformats

[Michael B. <mb...@de...>]

On Sat, Jan 08, 2011 at 05:12:40AM -0800, Emanoil Kotsev wrote:
> > Are you interested in any help with this that does not involve
> > signing a contributor agreement?
> > 
> 
> Licensing of synthesis was also my consideration. Interesting to know
> how Patrick has solved it into his project. I don't remember if I had
> to sign a license agreement when running syncevo the first time

Chris was talking about contributor agreements, not license agreements.
It is about when you donate code to the project, they want you to sign
over some parts of your copyright so they can potentially relicense the
code to their liking (either to another open source license, or
dual-license it with a proprietary license for their clients).  This
does not affect users of the software.


Michael

Re: [Opensync-devel] libsynthesis and vformats

[Lukas Z. <lu...@pl...>]

Hello,

On Jan 8, 2011, at 14:12 , Emanoil Kotsev wrote:

> In accordance to the message below I have a feeling that a lot in the concept of the opensync engine is similar to what I have researched in my studies in AI called autonomous agents or agent based architecture, though it's not exactly the same... opensync is somehow like a prototype for a coordinator (the hub). So if we were to borrow some wisdom from OAA (open agent architecture) we were to make the handling of the object types more autonomous or take the sync and merge functionality outside the engine (like default plugins filters or similar). My idea is that an obj can ask who can merge and get answer from the merger that will take over the job ...

Note that this is much closer to how libsynthesis actually works than it might seem. Of course it is now all integrated into one "engine", but the actual sync and merge is NOT done on vformat, but on abstracted data items. With some refactoring, sync and merge could be separated from formatting and talking to a peer.

Tight integration is needed between the vformat converters and the information a "engine" might have about the current peer. Because vformats (especially the old, but widespread ones) are too weak in specification and often too sloppily implemented to be handled without quite a bit of context about the sender/recipient. There's no such thing as a converter that can be fed only a vformat and produces sensible, normalized output (or vice versa).

Best Regards,

Lukas

Re: [Opensync-devel] libsynthesis and vformats

[Lukas Z. <lu...@pl...>]

Hello Chris,

On Jan 7, 2011, at 22:04 , Chris Frey wrote:

> I notice that there seems to be a difference in development and licensing
> strategies between OpenSync and libsynthesis.  Anyone can contribute
> to OpenSync and not have to sign anything, while it appears that
> contributing to libsynthesis requires signing a contributor agreement.
> This is off-putting to some developers.

The thing is, there's simply no money except our own (2 people) funding our work in libsynthesis, so we need the closed derived work (products we sell) to keep it going. That's why we have the contributor agreement. Without it, we cannot use contributions to libsynthesis ourselves which would essentially split the project into a internal and a public version. We'll not do that with the version we provide the infastructure for, but of course anyone who feels too much restrained by a contributor agreement could start maintaining a separate fork.

> I have some experience wrestling with vformat.c and incorporating it
> into the Barry plugin, as well as into the Barry library itself now.
> This is wasteful duplication, and it would be nice to see vformat
> support available generically.
> 
> Are you interested in any help with this that does not involve signing
> a contributor agreement?

The above explanation holds true for the classic libsynthesis. I can well imagine (however not guarantee anything at this time) that a separated vformat library could be handled differently. Unless it means directly killing my own income, I'm always open for open :-)

Lukas