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

Re: [Opensync-devel] Getting things back on track

[Henrik /K. <kaa...@us...>]

Dear all,

Three or four years ago I developed a piece of software - NokSync - to 
sync Mozilla to a Nokia mobile phone.
See http://www.kaarposoft.dk/noksync/
Users seemed to be quite happy with it! And so was I...
NokSync works only on windows and only with older versions of Nokia PC 
Suite.

So, two years ago I switched to Linux, and wanted to do the same.
OpenSync seemed like the perfect platform for this.
However, now - after two years - it still does not work...

OpenSync 0.40 seems just around the corner, but so it did 6 months ago, 
and 12 months ago.

So, I am taking a step back and asking myself:
What are we trying to accomplish?

----- oOo -----

My own "personal" goal is: From my Linux or Windows desktop, to sync 
Mozilla Thunderbird and Sunbird to any SyncML capable phone.
Or, I guess more generally, to allow an end user to:
Synchronize "any contact/calendar source" with any other such source(s).
Where a source could be a local device (mobile phone, PDA, etc), a local 
application (Thunderbird, Outlook, KDE Pim, Evolution, etc), or a remote 
application (GMail, etc).

Use Case:
I have a mobile phone, a GMail account, and a local Thunderbird 
installation. I want to keep those three in sync from my Linux or 
Windows desktop.

So, I ask myself: How can/should this be done?
What we need is:
1) A desktop application.
2) A protocol between the desktop app and each data source.
3) Capabilities in each data source to use the protocol.

Where (1) should maybe be extended to:
1a) Several desktop applications (KDE, GTK, Windows, ...)
1b) Plugins for existing local applications (KDE Pim, Thunderbird, ...) 
to provide an application-centric GUI
1c) A library for (1a) and (1b) to use

As for (2) - a protocol - I really only see one "standard" choice out 
there: SyncML.
So we could invent our own protocol (like in OpenSync) or stick to the 
"standard" SyncML.

Regarding (3):
Most mobile phones have SyncML capabilities.
Plugins exists for many applications to provide SyncML in one way or 
another - not all directly suited to our needs, but most could be used 
as building stones.

----- oOo -----

Funambol seems to be a successful solution to sync issues, and has 
native support or plugins for a multitude of devices and applications.
However, it deviates from "my objective" in one important way: it is 
based on a central server.
Devices / applications sync towards this central server.
You could implement such a sever on your own desktop (Funambol provides 
open sources for this), but sync would still be initiated by a 
device/application and sync towards one central database.

----- oOo -----

OpenSync - if we ever deliver - would implement most of "my objectives", 
but:
- will we ever deliver?
- OpenSync has invented it's own protocol - though SyncML is also 
supported via plugin.
- OpenSync will require custom-made plugins for each data source to be 
supported.
- As witnessed by this mailing list, it seems that the OpenSync design 
is so complicated and poorly documented, that willing contributors are 
scared off.

----- oOo -----

So, here is a proposal:

Let's create a new project (called newSyncML? OpenSyncML? ???)
In this project, let's develop
A) a library for SyncML synchronization
B) one or more desktop applications using (A)
C) one or more plugins for existing applications - using (A)
D) a library helping to develop a SyncML server for "any data-source"
E) plugins / applications / whatever for different data-sources to act 
as SyncML servers - possibly using (D)

(A) would mainly have to deal with data comparison and anchors and 
GUID/LUID mappings.

----- oOo -----

Daniel and others, I am sorry, but this is really a call for "Don't 
throw good money after bad".
I am considering whether OpenSync is really the way to go for "my 
objectives", and more and more it looks like a no...


What do you all think about this proposal?

/Henrik

Martin Owens wrote:
> Hey Paul,
>
> Perhaps the problem is that the opensync project has attempted to solve
> too many problems in the same framework?
>
>  * Data Access
>  * Data Formating
>  * Synchronisation Logic
>
> It would have probably have been a better idea if each of those problems
> had been solved separately but in ways that made them core components to
> the operating systems and perhaps in ways that made their extension
> trivial.
>
> Ubuntu still does not ship with any synchronisation functionality
> because compounding all problems into one project has made the entire
> thing a huge non-trivial problem.
>
> But perhaps it's too late now, I'm resined to the fact that I will never
> have good sync support and that every front end app will have poorly
> written data access, formating and syncing and the OS will never have
> anything definitive.
>
> Why are we trying to solve these problems? was it wise to write
> something that needed to be rewritten several times, whilst supporting
> obsolete versions and fracturing development effort and sapping the will
> of extension developers?
>
> I question the choices made in this project.
>
> Martin
>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Opensync-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensync-devel
>
>   

Re: [Opensync-devel] Getting things back on track

[Daniel G. <go...@b1...>]

Hi Martin,

long time no see ...

On Monday 19 October 2009 02:27:38 pm Martin Owens wrote:
> Perhaps the problem is that the opensync project has attempted to solve
> too many problems in the same framework?
> 
>  * Data Access
>  * Data Formating
>  * Synchronisation Logic
> 

Thats wrong - OpenSync actually only addresses: "Synchronisation Logic"

Data Access and Formating is done by plugins. And they actually should use 
libraries which have special formats or protocol implemented to convert a 
format or access a device to gather/write data.

e.g.:
 - palm-sync is using pilot-link / pisock
 - barry-sync is using the barry library
 - syncml obex plugin is using libsyncml, which is also using libopenobex


The only "data access" relevant thing in OpenSync are the plugin API calls. 
The only data formating calls are the format plugin API calls. There is no 
complex code inside OpenSync addressing this.

If there is one day a project doing perfect data formating of PIM data or any 
other data, there will be a OpenSync format plugin on the next day ... we 
don't have to change a single line in OpenSync core to make use of something a 
plugin like this ...


Best Regards,
Daniel

-- 
Daniel Gollub                        Geschaeftsfuehrer: Ralph Dehner
FOSS Developer                       Unternehmenssitz:  Vohburg
B1 Systems GmbH                      Amtsgericht:       Ingolstadt
Mobil: +49-(0)-160 47 73 970         Handelsregister:   HRB 3537
EMail: go...@b1...          http://www.b1-systems.de

Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg
http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D

Re: [Opensync-devel] Getting things back on track

[Daniel G. <go...@b1...>]

On Monday 19 October 2009 12:53:13 am Paul Eggleton wrote:
[...]
> I think it's plain to everyone that as a project we have a serious problem.
> Things are not moving forward at the pace that we really need them to and
>  have not been for quite some time, and this fact has not gone unnoticed by
>  the wider community. Every day people complain about the lack of decent
>  synchronisation support in open source products, so there is definitely
>  great demand - and yet OpenSync is still not ready to solve the problem.

Ack.

> 
> I just read a blog posting [1] by one of the Akonadi developers about some
> discussions that have gone on at their recent meeting. It seems for now
>  they have given up waiting for OpenSync and are looking at alternatives.
>  This is extremely unfortunate - historically I would have considered the
>  Akonadi project to be one of OpenSync's strongest allies.

Thats not new to me ... the kde-pim and akonadi developers stated this several 
times the last weeks/months. Not quite sure how many of them really checked if 
this true or not ...

But what they're doing is "just" moving KitchenSync and libqopensync to 
playground, which is a development branch AFAIK. Which sounds reasonable to me 
... so no reason to get panic.

But it's funny to see that Sascha Peilicke is commenting here ... you might 
remember him from the past when he complained about the glibc dependency of 
libsyncml ... (i still hope he mixed that up with glib ;))


> 
> Now, I recognise that many of us (especially me) have not contributed much
>  to the core of OpenSync. The problem there at least from my perspective is
>  that few of us have enough information about the vision behind the
>  OpenSync core or its internals in order to contribute effectively to it -
>  most of the responsibility these days falls on Daniel to answer any
>  questions or to make decisions.

Right.

>  Daniel, I do recognise that you don't have
>  as much time to work on OpenSync as you used to, and nobody would blame
>  you for that; however if the project is to go forward then something has
>  to change.

In fact things changed for me in mid September and last weeks very 
dramatically, in terms of spare time. But i still try to stick with the 
project and invest much as time as possible an reasonable. But private things 
come first ... i hope you understand that.

So you're completely right - and I also have concerns about the very low BUS-
factor [1] we have for OpenSync core development. If I disappear for a while 
OpenSync development trunk sometimes freezes. Maybe instead of concentrating 
on getting 0.40 out ASAP, i should try to get rid of this low BUS factor ... 
and concentrate on helping developers to start with core development 
primarily. I tried this now and then .. and succeed in some cases - e.g. 
Björn. But he has also limited spare time, like all of us. So we need more 
core developers to solve this problem. To bring this BUS factor high enough to 
speed up the trunk development in OpenSync core ...

Since i had the entire day to think about an solution, I'll come up with a new 
plan to address this BUS factor problem - in a separated mail.

[...]

> I myself stand fully ready to get involved more closely, but I need
>  guidance - documentation that covers the design foremost. In a number of
>  areas I would just need a few pointers on where to look, some commentary
>  on how things are supposed to work etc. and then I can fill in the blanks
>  and write full documentation. Armed with more information about OpenSync's
>  inner workings, perhaps more people can help solve the remaining issues
>  and finally get a stable release out there.

Thanks for your contribution and volunteering for core development ...

> 
> Let's get back on track!

Right, let's start ...


[...]

[1] http://en.wikipedia.org/wiki/Bus_factor

Best Regards,
Daniel

-- 
Daniel Gollub                        Geschaeftsfuehrer: Ralph Dehner
FOSS Developer                       Unternehmenssitz:  Vohburg
B1 Systems GmbH                      Amtsgericht:       Ingolstadt
Mobil: +49-(0)-160 47 73 970         Handelsregister:   HRB 3537
EMail: go...@b1...          http://www.b1-systems.de

Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg
http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D

Re: [Opensync-devel] Getting things back on track

[Martin O. <doc...@gm...>]

Hey Paul,

Perhaps the problem is that the opensync project has attempted to solve
too many problems in the same framework?

 * Data Access
 * Data Formating
 * Synchronisation Logic

It would have probably have been a better idea if each of those problems
had been solved separately but in ways that made them core components to
the operating systems and perhaps in ways that made their extension
trivial.

Ubuntu still does not ship with any synchronisation functionality
because compounding all problems into one project has made the entire
thing a huge non-trivial problem.

But perhaps it's too late now, I'm resined to the fact that I will never
have good sync support and that every front end app will have poorly
written data access, formating and syncing and the OS will never have
anything definitive.

Why are we trying to solve these problems? was it wise to write
something that needed to be rewritten several times, whilst supporting
obsolete versions and fracturing development effort and sapping the will
of extension developers?

I question the choices made in this project.

Martin

[Opensync-devel] Getting things back on track

[Paul E. <blu...@bl...>]

Hi all,

I think it's plain to everyone that as a project we have a serious problem. 
Things are not moving forward at the pace that we really need them to and have 
not been for quite some time, and this fact has not gone unnoticed by the 
wider community. Every day people complain about the lack of decent 
synchronisation support in open source products, so there is definitely great 
demand - and yet OpenSync is still not ready to solve the problem.

I just read a blog posting [1] by one of the Akonadi developers about some 
discussions that have gone on at their recent meeting. It seems for now they 
have given up waiting for OpenSync and are looking at alternatives. This is 
extremely unfortunate - historically I would have considered the Akonadi 
project to be one of OpenSync's strongest allies.

Now, I recognise that many of us (especially me) have not contributed much to 
the core of OpenSync. The problem there at least from my perspective is that 
few of us have enough information about the vision behind the OpenSync core or 
its internals in order to contribute effectively to it - most of the 
responsibility these days falls on Daniel to answer any questions or to make 
decisions. Daniel, I do recognise that you don't have as much time to work on 
OpenSync as you used to, and nobody would blame you for that; however if the 
project is to go forward then something has to change.

For OpenSync to be successful it needs to become a stable, working 
synchronisation platform that application developers (and users) can rely on. 
I feel like we're about 90% there, but we need to finish the last 10% or all of 
the work that has been done over the last few years will be mostly wasted.

I myself stand fully ready to get involved more closely, but I need guidance - 
documentation that covers the design foremost. In a number of areas I would 
just need a few pointers on where to look, some commentary on how things are 
supposed to work etc. and then I can fill in the blanks and write full 
documentation. Armed with more information about OpenSync's inner workings, 
perhaps more people can help solve the remaining issues and finally get a 
stable release out there.

Let's get back on track!

Cheers,
Paul

[1] http://www.omat.nl/2009/10/17/akonadi-meeting-day-1-discussions-api-
review/

Re: [Opensync-devel] [RFC] Change order of main/objtype plugin-sink function calls?

[Paul E. <blu...@bl...>]

On Sat, 17 Oct 2009, Henrik /KaarPoSoft wrote:
> As far as I am concerned, the modified proposed sequence is the "right"
>  one:
> 
> 1. Connect:
>    1.1 Main Sink connect()         <----- AS PROPOSED
>    1.2 ObjType Sink connect()      <----- AS PROPOSED
> 
> 2. Connect Done:
>    2.1 ObjType Sink connect_done() <----- FIFO
>    2.2 Main Sink connect_done()    <----- MAIN SINK LAST
> 
> 
> If everyone agrees that this is "conceptually" the right thing to do,
> it should be implemented in OpenSync, and if plugins need to be adjusted,
> so be it.

Agreed, this makes sense.

FWIW, the patch does work for me though.

Cheers,
Paul

Re: [Opensync-devel] [RFC] Change order of main/objtype plugin-sink function calls?

[Henrik /K. <kaa...@us...>]

Hi,

I am sorry, but I do not think this is a question of whether the patch 
works.

As far as I am concerned, the modified proposed sequence is the "right" one:

1. Connect:
   1.1 Main Sink connect()         <----- AS PROPOSED
   1.2 ObjType Sink connect()      <----- AS PROPOSED

2. Connect Done:
   2.1 ObjType Sink connect_done() <----- FIFO
   2.2 Main Sink connect_done()    <----- MAIN SINK LAST


If everyone agrees that this is "conceptually" the right thing to do,
it should be implemented in OpenSync, and if plugins need to be adjusted,
so be it.

/Henrik


Daniel Gollub wrote:
> On Saturday 17 October 2009 05:52:22 pm Paul Eggleton wrote:
>   
>> Hi all,
>>
>> So, any further thoughts/objections on this one? If not, it would be nice
>>  to get the change made (at least for the connect)
>>     
> [...]
>
> Did you try the proof of concept patch? Is your plugin working with this patch 
> as expected?
>
> Best Regards,
> Daniel
>
>   

Re: [Opensync-devel] [RFC] Change order of main/objtype plugin-sink function calls?

[Daniel G. <go...@b1...>]

On Saturday 17 October 2009 05:52:22 pm Paul Eggleton wrote:
> Hi all,
> 
> So, any further thoughts/objections on this one? If not, it would be nice
>  to get the change made (at least for the connect)
[...]

Did you try the proof of concept patch? Is your plugin working with this patch 
as expected?

Best Regards,
Daniel

-- 
Daniel Gollub                        Geschaeftsfuehrer: Ralph Dehner
FOSS Developer                       Unternehmenssitz:  Vohburg
B1 Systems GmbH                      Amtsgericht:       Ingolstadt
Mobil: +49-(0)-160 47 73 970         Handelsregister:   HRB 3537
EMail: go...@b1...          http://www.b1-systems.de

Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg
http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D

Re: [Opensync-devel] [RFC] Change order of main/objtype plugin-sink function calls?

[Paul E. <blu...@bl...>]

Hi all,

So, any further thoughts/objections on this one? If not, it would be nice to 
get the change made (at least for the connect)

Cheers,
Paul

[Opensync-devel] xmlformat_compare not working for sub-fields

[Henrik /K. <kaa...@us...>]

xmlformat_compare has a nice way of comparing OSyncXMLFields; adding and 
subtracting "points" to see how well two OSyncXMLFormats match.
However, this does *not* extend to sub-fields.

If we have
  <Name>
    <LastName>Doe</LastName>
    <FirstName>John</FirstName>
  </Name>
and compare to
  <Name>
    <LastName>Doe</LastName>
    <FirstName>John</FirstName>
    <Prefix>Mr.</Prefix>
  </Name>
the two fields will not match, resulting in a -90 points penalty.

Even worse, if we have
  <Name>
    <LastName>Doe</LastName>
    <FirstName>John</FirstName>
  </Name>
and compare this to how file-sync currently reports vcards to xml:
  <Name>
    <LastName>Doe</LastName>
    <FirstName>John</FirstName>
    <Additional></Additional>
    <Prefix></Prefix>
    <Suffix></Suffix>
  </Name>
the two fields will not match either
(we get "Run out of list2 elements. Different.")

Does anyone have a good idea as to how to resolve this issue?

/Henrik

Re: [Opensync-devel] [RFC] Change order of main/objtype plugin-sink function calls?

[Henrik /K. <kaa...@us...>]

On Sunday 27 September 2009 12:22:00 pm Paul Eggleton wrote:
> [...]
>   
>> I've just recently changed opie-sync to do the connection to the device in
>>  a main sink rather than checking if it needed to be done within each
>>  objtype sink. However I have come accross some behaviour that I don't
>>  understand. It seems the main sink only connects after all of the objtype
>>  sinks have connected.
>>     
>   
Daniel wrote:
> New Implementation (proposal):
> -----------------------------
>
> 1. Connect:
>    1.1 Main Sink connect()         <----- CHANGED
>    1.2 ObjType Sink connect()      <----- CHANGED
>
> 2. Connect Done:
>    2.1 Main Sink connect_done()    <----- CHANGED
>    2.2 ObjType Sink connect_done() <----- CHANGED
>
>   
If the point of this change is to let the main sink handle some device 
initialization in connect, I think it makes more sense to also allow the 
main sink handle device finalization in done, so I would think this 
sequence makes more sense:

1. Connect:
   1.1 Main Sink connect()         <----- AS PROPOSED
   1.2 ObjType Sink connect()      <----- AS PROPOSED

2. Connect Done:
   2.1 ObjType Sink connect_done() <----- FIFO
   2.2 Main Sink connect_done()    <----- MAIN SINK LAST

/Henrik

Re: [Opensync-devel] [RFC] Change order of main/objtype plugin-sink function calls? (was: Main sink connecting)

[Paul E. <blu...@bl...>]

Hi Daniel,

On Sat, 10 Oct 2009, Daniel Gollub wrote:
> New Implementation (proposal):
> -----------------------------
> 
> 1. Connect:
>    1.1 Main Sink connect()         <----- CHANGED
>    1.2 ObjType Sink connect()      <----- CHANGED
> 
> 2. Connect Done:
>    2.1 Main Sink connect_done()    <----- CHANGED
>    2.2 ObjType Sink connect_done() <----- CHANGED

Changing the connect would be good for me obviously, but I'm not sure about 
connect_done - for my plugin I don't use it, so I'm not sure of its 
intended/current usage, but it's possible you may want the main sink to have 
the last "say" for this latter function.

I'll be interested to hear what the other plugin devs think about this.

Cheers,
Paul

[Opensync-devel] [RFC] Change order of main/objtype plugin-sink function calls? (was: Main sink connecting)

[Daniel G. <go...@b1...>]

On Sunday 27 September 2009 12:22:00 pm Paul Eggleton wrote:
[...]
> I've just recently changed opie-sync to do the connection to the device in
>  a main sink rather than checking if it needed to be done within each
>  objtype sink. However I have come accross some behaviour that I don't
>  understand. It seems the main sink only connects after all of the objtype
>  sinks have connected.

Correct, main sink comes always after the objtype sinks. Not only for 
connect(-phase) ...


>  In my case I need to connect to the device, and then
>  after that I need to determine for each objtype whether slow-sync is
>  required; this latter task needs to be done at the connect stage I
>  believe.

Ah ok. I'm not quite sure yet if there would be any downside if we would 
change this to something like that:


Current Implementation:
-----------------------

1. Connect:
   1.1 ObjType Sink connect()
   1.2 Main Sink connect()


2. Connect Done:
   2.1 ObjType Sink connect_done()
   2.2 Main Sink connect_done()

3. Read (optional, only used if conflicts got ignored on a  previous sync)
   3.1 ObjType Sink Read ignored changes read()
  (3.2 Main Sink read ignored changes read()) FIXME: not implemented ... :/

4. Get Changes:
   4.1 ObjType Sink get_changes()
   4.2 Main Sink get_changes()

5. Commit:
   5.1 ObjType Sink write()
   5.2 Main Sink write()

6. Sync Done:
   6.1 ObjTYpe Sink sync_done()
   6.2 Main Sink sync_done()

7. Disconnect
   7.1 ObjType disconnect()
   7.2 Main Sink disconnect()

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

New Implementation (proposal):
-----------------------------

1. Connect:
   1.1 Main Sink connect()         <----- CHANGED
   1.2 ObjType Sink connect()      <----- CHANGED

2. Connect Done:
   2.1 Main Sink connect_done()    <----- CHANGED
   2.2 ObjType Sink connect_done() <----- CHANGED

3. Read (optional, only used if conflicts got ignored on a  previous sync)
   3.1 ObjType Sink Read ignored changes read()
  (3.2 Main Sink read ignored changes read()) FIXME: not implemented ... :/

4. Get Changes:
   4.1 ObjType Sink get_changes()
   4.2 Main Sink get_changes()

5. Commit:
   5.1 ObjType Sink write()
   5.2 Main Sink write()

6. Sync Done:
   6.1 ObjTYpe Sink sync_done()
   6.2 Main Sink sync_done()

7. Disconnect
   7.1 ObjType disconnect()
   7.2 Main Sink disconnect()





I quickly tested if i change the order only for the connect phase - the 
testsuite resutls looks pretty good:

http://opensync.org/testing/buildSummary.php?buildid=10940

The 4 tests which fail looks like only testcases which tried to verify the old 
order (1. main sink, 2. objtype sink ...) which just require quick adaption 
...


>  I don't think the way it works now will let me do that without
>  going back to having the main connect logic in each objtype sink's connect
>  function;

Ok, i see. This would be bad... so we should try to avoid this redudant 
connect implementaiton - right?

>  but if I do go back I can't retrieve a few stored values that I
>  am (at the moment) putting into the main sink's state db.

I see ...

> 
> I assume this connect order is intentional. If so, what is the reason for
> doing it this way?

I can't remember if there was any real intention doing this order .. so this 
was implemented this way by Armin before my time doing 0.3x development... 
currently i don't see any reason changing the order for connect. I would keep 
the 1. master, 2. objtype-sink order for disconnect ... 



All, anyone who would face issues changing the objtype-sink order for connect 
and connect_done? Would anyone see advantages changing the order for other 
plugin-sink functions?

Best Regards,
Daniel

-- 
Daniel Gollub                        Geschaeftsfuehrer: Ralph Dehner
FOSS Developer                       Unternehmenssitz:  Vohburg
B1 Systems GmbH                      Amtsgericht:       Ingolstadt
Mobil: +49-(0)-160 47 73 970         Handelsregister:   HRB 3537
EMail: go...@b1...          http://www.b1-systems.de

Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg
http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D

Re: [Opensync-devel] why long long?

[Henrik /K. <kaa...@us...>]

Daniel Gollub wrote:
> On Friday 09 October 2009 09:35:59 pm Chris Frey wrote:
>   
>> Why is the member ID so large?  Is there really a risk of
>>  9223372036854775807 different members?
>>
>> The reason I ask is that 'long long' is not as portable as just long, and
>> there is no reason for such a large number, as far as I can see.
>>     
>
> No idea, this was introduced long before i joined the OpenSync development.
> We should have a look into the subversion logs if Armin mentioned any reason 
> to use long long ...
>
> How many public member/group interfaces are using long long?
>
>   
If we really want to stick to the frozen interface, we could use gint64
http://library.gnome.org/devel/glib/stable/glib-Basic-Types.html#gint64

(This would be "binary compatible" with current API for most platforms I 
guess,
yet be more portable).

However, I guess that long int should be more than enough...

/Henrik

Re: [Opensync-devel] why long long?

[Daniel G. <go...@b1...>]

On Friday 09 October 2009 09:35:59 pm Chris Frey wrote:
> Why is the member ID so large?  Is there really a risk of
>  9223372036854775807 different members?
> 
> The reason I ask is that 'long long' is not as portable as just long, and
> there is no reason for such a large number, as far as I can see.
> 

No idea, this was introduced long before i joined the OpenSync development.
We should have a look into the subversion logs if Armin mentioned any reason 
to use long long ...

How many public member/group interfaces are using long long?

Best Regards,
Daniel


-- 
Daniel Gollub                        Geschaeftsfuehrer: Ralph Dehner
FOSS Developer                       Unternehmenssitz:  Vohburg
B1 Systems GmbH                      Amtsgericht:       Ingolstadt
Mobil: +49-(0)-160 47 73 970         Handelsregister:   HRB 3537
EMail: go...@b1...          http://www.b1-systems.de

Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg
http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D

[Opensync-devel] why long long?

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

Hi,

While reading the opensync API from the application perspective, group
members are referred to by their ID, and this ID is a long long int.

In output from commands such as osynctool --showgroup GroupName, these
ID numbers start from 1.

Why is the member ID so large?  Is there really a risk of 9223372036854775807
different members?

The reason I ask is that 'long long' is not as portable as just long, and
there is no reason for such a large number, as far as I can see.

Thanks,
- Chris


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

[Opensync-devel] Important bug going unfixed

[Adam W. <awi...@ma...>]

Hi, guys. Just wondered if anyone had time to look at
https://www.opensync.org/ticket/1131 , which makes synce synchronization
with 0.22 useless (with python 2.6), we believe - any synchronization
after the first fails. there's a workaround in the report, but it's a
patch to the python code generated from C source by SWIG, and no-one
currently looking at the report knows how to fix it in the original C,
so it's been lying stagnant for a while. I may try and ram a bodge into
the opensync package for Fedora 12 so the functionality is available,
but it'd be nicer to have a proper fix. thanks!

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

Re: [Opensync-devel] bounty for enterprise ready synchronization with floss servers

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

On Tuesday 06 October 2009 09:56:09 Jelle de Jong wrote:
> Somebody that want to respond to this? Is the bounty to low, or do you
> rather want to help coach a student or an other professional linux
> developer? If there is something else that bothers you just make it
> clear so we can take the next steps.

I am only a small contributor and I cannot speak for the project leads, 
however my guess is that the main problem is that there is no one working on 
the project who has the time available to take up the bounty offer.

The main thing the project needs is to get some more developer-hours applied.  
The basic engine still has some problems at the moment and, in some cases, 
there are ideas about how to fix them but still work to do (certainly true in 
my case).  And we haven't started any serious testing yet!

I do not want to minimise, of course, the strong contributions made by the 
existing team.  But if no one from the existing OpenSync community steps up, 
you may want to look at whether you could use your bounty to attract one or 
more new developers to join the project.

Graham

Re: [Opensync-devel] bounty for enterprise ready synchronization with floss servers

[Jelle de J. <jel...@po...>]

On 09/28/09 14:58, Jelle de Jong wrote:
> On 09/28/09 03:53, Chris Frey wrote:
>> On Sun, Sep 27, 2009 at 09:13:43PM +0200, Jelle de Jong wrote:
>>> syncml-ldap plugin that can sync contacts with an openldap server
>>> http://www.opensync.org/ticket/1069
>>
>> According to my understanding of how opensync works, this is
>> two plugins, no?  A syncml plugin + opensync + an LDAP plugin.
>>
>> And don't things things already exist, with varying 50% to 90%
>> completion?
>
> Most basic blocks do exist but are not available as working libraries
> with API's for GUI/CLI developers.
>
> I have been able to pull out the contact, email, calender information
> from my SyncML capable Nokia telephone with bluetooth. However this
> information alone is still useless. I got an imap, caldav and openldap
> server. (we are not talking about MUA clients)
>
> I would like to see that the OpenSync tools that gather the data with
> SyncML and then login into the respective services of the server(s) and
> synchronize the data, without going pass a MUA. There should also be
> libraries available that do imap, caldav and openldap.
>
> These blocks/libraries/documentation needs to be improved where
> necessary to make the above all work. Then a GNOME/KDE/XFCE/CLI/whatever
> developer can use this to make a perfect GUI for the end user that can
> input the servers accounts and connection information and make the
> synchronization action happen. This can all be done with bluetooth or
> the other connection that SycML/OpenSync supports.

Somebody that want to respond to this? Is the bounty to low, or do you 
rather want to help coach a student or an other professional linux 
developer? If there is something else that bothers you just make it 
clear so we can take the next steps.

Best regards,

Jelle

Re: [Opensync-devel] Integration with iTunes

[Friedrich B. <fri...@gm...>]

Hi,

I guess the build hints are outdated. The ones that I made
are here:

http://opensync.org/wiki/trunk/windows

Cheers

Friedrich

Henrik /KaarPoSoft schrieb:
> Hi Todd,
> 
> I have tried to build OpenSync and the mozilla-sync plugin on Windows.
> You can have a look here: 
> http://bluezync.kaarposoft.dk/building.html#building_windows
> However, since Mozilla now recommends using Visual Studio Express from 
> Microsoft (free, but not open source), I will try this instead.
> 
> There are also some windows building instructions here: 
> http://opensync.org/wiki/devel/compilingForWindows
> but note that they use cygwin, so my guess is that although OpenSync 
> might build, you will have problems with Mozilla.
> 
> Be warned, that buidling OpenSync and mozilla-sync on a non-linux 
> platform is NOT easy !
> 
> Apart from that, it would be great to have a iTunes plugin - for any 
> platform...
> 
> /Henrik
> 
> 
> Todd Nine wrote:
>> Hi all,
>>   I'm working on trying to integrate Mozilla Lightning and Sunbird 
>> with iTunes.  It seems like a lot of sync work has already been done 
>> with the mozilla plugin that will allow me to interact with the 
>> calendar.  From my basic understanding of the API, I can write a sync 
>> plugin for iTunes that will allow iTunes integration with any plugin 
>> that opensync provides.  Given that my initial target release will be 
>> Windows, are there any good examples of creating a simple binary that 
>> can be used on the Windows platform?  I want to make installation of 
>> this iTunes plugin easy, so I just want to include the neccessary DLL 
>> files within my plugin.
>>
>> Thanks,
>> Todd
> 
> 
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Opensync-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensync-devel
> 

-- 
=====================================================
Friedrich Beckmann, Siegfriedstr. 33, 90461 Nürnberg
Tel: 0911-5443044; Mobil: 017648576782

Re: [Opensync-devel] Integration with iTunes

[Henrik /K. <kaa...@us...>]

Hi Todd,

I have tried to build OpenSync and the mozilla-sync plugin on Windows.
You can have a look here: 
http://bluezync.kaarposoft.dk/building.html#building_windows
However, since Mozilla now recommends using Visual Studio Express from 
Microsoft (free, but not open source), I will try this instead.

There are also some windows building instructions here: 
http://opensync.org/wiki/devel/compilingForWindows
but note that they use cygwin, so my guess is that although OpenSync 
might build, you will have problems with Mozilla.

Be warned, that buidling OpenSync and mozilla-sync on a non-linux 
platform is NOT easy !

Apart from that, it would be great to have a iTunes plugin - for any 
platform...

/Henrik


Todd Nine wrote:
> Hi all,
>   I'm working on trying to integrate Mozilla Lightning and Sunbird 
> with iTunes.  It seems like a lot of sync work has already been done 
> with the mozilla plugin that will allow me to interact with the 
> calendar.  From my basic understanding of the API, I can write a sync 
> plugin for iTunes that will allow iTunes integration with any plugin 
> that opensync provides.  Given that my initial target release will be 
> Windows, are there any good examples of creating a simple binary that 
> can be used on the Windows platform?  I want to make installation of 
> this iTunes plugin easy, so I just want to include the neccessary DLL 
> files within my plugin.
>
> Thanks,
> Todd

[Opensync-devel] Integration with iTunes

[Todd N. <tod...@gm...>]

Hi all,
  I'm working on trying to integrate Mozilla Lightning and Sunbird with
iTunes.  It seems like a lot of sync work has already been done with the
mozilla plugin that will allow me to interact with the calendar.  From my
basic understanding of the API, I can write a sync plugin for iTunes that
will allow iTunes integration with any plugin that opensync provides.  Given
that my initial target release will be Windows, are there any good examples
of creating a simple binary that can be used on the Windows platform?  I
want to make installation of this iTunes plugin easy, so I just want to
include the neccessary DLL files within my plugin.

Thanks,
Todd

[Opensync-devel] localization in plugin configs

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

Hi,

Trying to wrap my head around the plugin config API and the schemas.

I notice that there are Advanced Options, with settings like DisplayName,
Max, Min, Value, etc.

Then there is a Localization "config group" that has Encoding, Timezone,
and Language.

My question is, how does the Language from Localization affect the
DisplayName from AdvancedOptions?

For example, if DisplayName for a given option is "Probulator Intensity",
where would the translations be stored?

Thanks,
- Chris


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [Opensync-devel] dual installs of 0.22 and 0.4x

[Juha T. <Juh...@ik...>]

On Wednesday 30 September 2009 02:47:36 Chris Frey wrote:
> The 3 main changes are now finished:
> 	- using XDG_CONFIG_HOME, defaulting to ~/.config/opensync/0.40
> 	- the copy upgrade behaviour: when creating ~/.config/opensync/0.40
> 	- libopensync.pc was renamed to libopensync1.pc, with updates to
> I'm much happier now. :-)  Thanks for the feedback folks.

Me too! I wish all opensource desktop software would treat
NFS and enterprise users like opensync does. :)

Tuju

-- 
Better to have one, and not need it, than to need one and not have it.

Re: [Opensync-devel] dual installs of 0.22 and 0.4x

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

On Sun, Sep 27, 2009 at 04:01:08AM -0400, Chris Frey wrote:
> On Sun, Sep 27, 2009 at 09:49:09AM +0200, Daniel Gollub wrote:
> > Ok, sound good to me - could you implement (and commit) the required changes? 
> > And do basic testing for 0.22 as well?
> 
> Certainly.  I don't plan on making any changes to 0.22 at all, but I do
> need to test to make sure a 0.40 subdirectory doesn't confuse 0.22.
> I don't think 0.22 does a recursive search for "group?" directories,
> does it?  I'll test though.

The 3 main changes are now finished:

	- using XDG_CONFIG_HOME, defaulting to ~/.config/opensync/0.40

	- the copy upgrade behaviour: when creating ~/.config/opensync/0.40
		for the first time, it copies any existing ~/.opensync/group*
		directories into 0.40

	- libopensync.pc was renamed to libopensync1.pc, with updates to
		cmake configs

Version 0.22 does not recurse into the 0.40 directory, so even if 0.40
was inside ~/.opensync (which it isn't anymore) version 0.22 would not
be bothered.

I'm much happier now. :-)  Thanks for the feedback folks.

- Chris


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.