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

Re: [Opensync-devel] Fixing the OpenSync core development BUS factor

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

On Sunday 25 October 2009 20:25:15 Jakub Marczynski wrote:
> - Due to very limited time (as most of us have) I would prefer to have
> another person doing the same component with me. This way we increase the
> BUS Factor even more.

That sounds like a good idea.  We all have limited time and if there were a 
couple of people working together in one area we could use it to discuss 
ideas but also, hopefully, keep some more momentum going.  Of course, there 
are also the problems of treading on each others toes which we would have to 
manage.  One of the things that has frustrated me in the past is that I have 
a suggestion or thought about an issue or a solution and no one seems to be 
interested in discussing it with me!  Of course, I am guilty of exactly the 
same thing in other areas.

> - I'm afraid I'll need another 2-3 weeks to look through the opensync.org
> website, the existing documentation, the code itself, to get some generall
> idea how stuff work

Do post questions here.  Although Daniel and Bjorn are the main experts I am 
happy to commit to reading and answering when I can.

> - How can You (existing core developers) pass some knowledge to Us (new
> developers) so that we know where to start and what to do? Did you think of
> another IRC meetings? Or maybe some private Skype sessions ( 1 to 1) would
> be more efficient?

Scheduling IRC meetings can be difficult, although I think many of the 
developers are in Europe.  For me personally it is a problem because my job 
requires a lot of travel (both East and West) so I can't commit to any 
regular meetings.  

Where possible it would be great to keep discussions in the open, and in an 
archive, to help others.  Is the IRC channel archived?  However, if there are 
a couple of people working in one area then voice discussions can also work 
(although I would still encourage email dicussions to happen on the list so 
others can learn and can contribute).

Graham

[Opensync-devel] [RFC] Using OSYNC_START_TYPE_EXTERNAL

[Henrik /K. <he...@ka...>]

Dear all,

I am working on porting mozilla-sync to use OSYNC_START_TYPE_EXTERNAL.

I have a "proof-of-concept" which works "by hand" in a debugging 
environment. I will provide details later on this list for those who 
might me interested.

However, there are two conceptual issues, that I would like to discuss 
with the community:
(1) How to start the external process
(2) How to tell the external process which pipe to use

Currently, in my mozilla-sync "proof-of-concept" I do this:
a) use osynctool to create group and members
b) launch osynctool --discover or --sync
c) manually start the external process and pass it the pipe name on the 
command line (using a pipe name I worked out "manually" using knowledge 
on how OpenSync works, and the groups I created)

In principle, this could also be used in a production environment.

However, this means that it will be the resposability of the caller to 
create the external process, and pass the name of the pipe to it.

This can be a bit tricky, especially if the caller did not create the 
group/members in the first place.

I.e. before launching osynctool (or, in a production environment: before 
starting your own sync in your own GUI), you would need to work out 
which external processes to start, and which pipenames to pass to it, 
and how. It would be difficult for a generic GUI to know how to do this.

Even in the case-in-point (mozilla-sync) it is difficult. Yes the GUI 
plugin could osync_member_get_configdir and append /pluginpipe, but this 
really makes a lot of assumptions on closed OpenSync functionality. And 
if we do a mozilla-sync to mozilla-sync sync, it gets even more long-haired.

So, how do we solve the two issues:
(1) How to start the external process
(2) How to tell the external process which pipe to use

I think that the information on those issues needs to be carried in the 
plugin configurations.

If this could be made to work, "any" generic GUI could just start the 
sync, and the plugin/OpenSync would take care of the rest.

Proposal:

We could add a function called osync_plugin_set_start_external_command 
in opensync_plugin to be called from get_sync_info:

This function could be passed a string in printf format (e.g. 
"start-external-process %s"), and osync_client_proxy_spawn could call 
g_strdup_printf with the pipe name as an argument, and execute the 
resulting command with g_spawn_command_line_async.

I do not know about other external processes, but with blueZync plugin 
installed, if you launch "thunderbird --mozilla-sync=/path/to/pipe" it 
will create a new thunderbird instance if one is not already running, 
otherwise it will connect to the running thunderbird, which is exactly 
what we need.

Comments on this would be most appreciated.

/Henrik

Re: [Opensync-devel] Fixing the OpenSync core development BUS factor

[Jakub M. <ja...@o2...>]

Daniel Gollub mentioned several component to be taken care of:
 - Application API
 - (Sync) Plugin API
 - Format Plugin API
 - Synchronization Engine (workflow of the Synchronization: connect,
 - Format Conversion (abstract logic to convert formats, e.g. conversion
 - Mapping Logic (abstract logic to compare and map similar/same entries)
 - Capabilties, Merger and Demerger
 - IPC

I think I will be able to do some work on the project in the following 
months, but:
- Due to very limited time (as most of us have) I would prefer to have 
another person doing the same component with me. This way we increase the 
BUS Factor even more.
- I'm afraid I'll need another 2-3 weeks to look through the opensync.org 
website, the existing documentation, the code itself, to get some generall 
idea how stuff work
- How can You (existing core developers) pass some knowledge to Us (new 
developers) so that we know where to start and what to do? Did you think of 
another IRC meetings? Or maybe some private Skype sessions ( 1 to 1) would 
be more efficient?

---
Bloosky
ja...@o2...

[Opensync-devel] [RFC] Do not clone-demerge-compare, just compare taking capabilities into account

[Henrik /K. <he...@ka...>]

Dear all,

Following up on a previous thread on this list:

>> The current logic in _osync_obj_engine_mapping_find is:
>> Clone (i.e. make a complete copy of) change1. Demerge fields from the
>> clone which are not in caps2.
>> Clone (i.e. make a complete copy of) change2. Demerge fields from the
>> clone which are not in caps1.
>> Compare the two cloned objects.
>> To me this seems unnecessarily complicated and incurs a performance
>>  penalty. Why is this not implemented as a more "intelligent" compare
>>  function, which takes capabilities into account?

> This is pretty new code and more or less just a proof of concept. If you came 
> up with a more efficient solution, let me know. This was the last thing i was 
> working on ... it's not completed.


OK, here is a suggestion:

In  _osync_obj_engine_mapping_find in opensync_obj_engine.c we currently have something which boils down to:

clone_change1 = _osync_obj_engine_clone_and_demerge_change(sinkengine->engine, caps2, change1, error);
clone_change2 = _osync_obj_engine_clone_and_demerge_change(sinkengine->engine, caps1, change2, error);
change1 = clone_change1;
change2 = clone_change2;
tmp_result = osync_change_compare(change1, change2, error);

This could be replaced with

tmp_result = osync_change_compare(change1, change2, caps1, caps2, error);

osync_change_compare and thus osync_data_compare and osync_objformat_compare and maybe other functions would require trivial changes.

It would then boil down to modifying functions like osync_objformat_compare to take capabilities into account (not trivial).

As far as I can see, this would be a far more efficient solution.

The drawback is of course that it needs coding work (=time).

However, as demerge_xmlformat needs heavy work anyway, I think this may be a good time to consider replacing clone-demerge-compare with a compare taking capabilities into account.

What do you all think about this proposal?

/Henrik

PS: This was about demerge. I have not quite figured merge out, maybe somebody more knowledgeable than me could comment on this...

Re: [Opensync-devel] A more radical approach: Kill the mozilla-sync plugin ??

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

On Saturday 24 October 2009 02:07:02 pm Henrik /KaarPoSoft wrote:
[...]
> Following up on my earlier posts, here is my latest, crazy idea: Kill
> the mozilla-sync plugin.
> 
> 
> As mentioned before, the current design is flawed (using not-thread-safe
> functions from Mozilla in threads), does not work with Thunderbird 3,
> and is a nightmare to port between platforms - even between different
> linux distros.
> 
> Instead of using more development time on the mozilla-sync plugin,
> syncing Mozilla could be accomplished by
> - using the syncml-http-server plugin in OpenSync
> - using the Funambol Thunderbird extension
> (https://mozilla-plugin.forge.funambol.org/)

How complicated would be the setup to get this kind of sync working?
I wonder if this would allow kind of a out-of-the box setup?


When Armin and others decided to implement a IPC system in OpenSync they also 
introduced this three  "ProcessStartTypes" for plugin:

 - thread (default)
 - process (fork - runs in the osplugin wrappe process)
 - external (communication via FIFO)

The later one was iirc the idea to be used for applications like thunderbird 
or mozilla, which didn't provide any public API or easy to handle API to sync.

so if the funambol thunderbird extension doesn't work out ... whabt about 
writing an "OpenSync extension" for thunderbird?

This extension is more or less a OpenSync plugin living inside this extension. 
This extension would then communicate with the OpenSync framework via a fifo 
... ipc/fifo setup is all handled by the OpenSync API - AFAIK.

Unfortuantely there is no real-life example yet, but the code for those 
external plugins exists. Need to check if i can make up an example out of 
testcases ...

Or would this be no option for you?
I could imagine something like this would allow simpler setup ... since you 
don't have to setup things like an local IP connection or so. For an regular 
users this would be a bit confusing to configure a "network" connection to 
talk to a local running application - right?

But i see your point in avoiding redudant-code or reinventing the wheel and so 
..

[...]
> 
> 
> Then there is the question of GUI...
> 
> blueZync is a GUI for OpenSync in Mozilla.
> It does not suffer from the mozilla-sync design flaw or Thunderbird 3
> incompatibility, but is still difficult to port, and not really
> satisfactory.
> I am thinking about killing this one as well, and maybe work on a GTK+
> replacement for kitchensync.

Acutally you would work on a replacement of MultiSync-0.90 - which is a 
OpenSync GTK gui .. currently AFAIK unmaintined.

There is also gnome-sync-tool you might want to have a look at.

> Maybe this GUI could even be launched from within Mozilla with a small
> plugin.

Yeah, this would be indeed very intersting. But i'm not familiar with Mozilla 
how this works ...

You don't have to use KitchenSync as _the_ ideal OpenSync GUI. You could also 
write some Mozilla plugin(s) which just setup a sync with dedicated plugins - 
e.g. Mobile-Sync-Plugin for Mozilla

Which provides a very simple UI to setup a group of a mozilla-plugin and the 
syncml-obex-client and maybe some other (synce, gnokii-sync, ...) just 
dedicated for mobile syncing ... so you don't have to write a UI to create 
generic groups for all available plugins and so.

Just an UI which provides a search-bluetooth-device UI or so and setups a 
group with the best fitting plugin on the fly. But the end-user doesn't see 
anything that there got a group with member created - your app doesn't need to 
support multiple groups and so ...

> 
> 
> Your comments and thoughts about the above would be much appreciated.
[...]

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] Fixing the OpenSync core development BUS factor

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

On Tuesday 20 October 2009 08:02:10 pm Dirk Wischeropp wrote:
> Yes there are. My name is Dirk and i am new to opensync. I am reading
> this mailing list in a while and I am interested for this project.
> I am studing computer science. I had considered some time ago to expand
> my programming skills to participate in an open source project times.
> Unfortunately I have only basic skills at this time.
> 
> But I hope I can help you?

Sure you can.

First i would suggest that you get in touch with the build enviroment and 
trunk/

Checkout latest trunk and build it and try to setup a group with two file-sync 
plugins. For beginning core development this is bascially enough.

Try to do some syncing first - if you hit any problem - create a ticket and 
try on your own to fix it. If you have trouble understanding the code - ask 
here on the mailinglist. start a new thread for that ;)


If you like I can look for a trivial ticket to solve you can start with ... so 
you have kind of a task to work on.


Thanks for your help!

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] Questions about capabilities

[Henrik /K. <he...@ka...>]

Daniel Gollub wrote:
> On Friday 23 October 2009 11:32:46 am he...@ka... wrote:
>   
>> 1)
>> In capabilities.xsd we have an element called Parameter with
>> maxOccurs="unbounded".
>> In opensync_capability.h/c we have osync_capability_set_parameter whichs
>> sets ONE parameter.
>> As far as I can see, it sould be possible to have several parameters (such
>> as both Location and Pref for an Address).
>> So: is this a bug in the capabilities API (i.e. opensync_capability.h/c)?
>>     
>
> Yes, that's a bug - we need to break the API for this ...
>   
ACK. Maybe one day I will provide a patch...
>
>   
>> 2)
>> A well-formed XML document must have exactlny one root node.
>> According to capabilities.xsd the root node must be <Caps> which has an
>> attribute called CapsFormat.
>> If a plugin is offering capabilities in different CapsFormats (e.g.
>> because it supports both vformat and xmlformat), how would this be
>> specified?
>> Suggestion: Rename <ObjType> to <ObjTypeCaps> and move the CapsFormat
>> attribute from <Caps> to <ObjTypeCaps>.
>> (API change probably needed as well).
>>     
> This requires some more discussion i guess. Actually the capsformat is 
> independent of the objformat .... i still need to describe how the capsformat 
> thing works. I will go in more details in a separated mail about capsformat 
> ...
>   
Looking forward to that!
>> 3)
>> capabilities.xsd defines that <Cap> can have a <DisplayName> child, and
>> that <Parameter> can have a <DisplayName> child.
>> When would we ever want to show an end-user the name of a capability or
>> parameter?
>>     
>
> Maybe thats useful to let user now which fields will be not synced and due to 
> missing capabilities support - and will not get lost.
>
> The idea of DisplayName comes from SyncML - SyncML spec has this defined. So 
> some phones are providing this information .. so if this is available we might 
> want to use this information on the first Sync or so to inform the users which 
> fields will not appear on member X..
>   
Right, but I do not think this DisplayName should come from the caps, it 
should come from the format...
>> 4)
>> capabilities.xsd defines that <Cap> can have a <MaxOccurs> child, but no
>> <MinOccurs> child.
>> Is this a mistake, or is it because the demerger would not be able to
>> handle it anyway (i.e. what should the merger do if the change does not
>> include the attribute for which MinOccurs > 0 ? )
>>     
>
> We still can add this .. but first there needs to be a real use case in the 
> "wild" ... This capabilities schema is based on the capabilities description 
> from SyncML specs. AFAIK they haven't minoccurs either ...
>   
I could not find MaxOccurs (or MinOccurs) in SyncML.
> Maybe if minoccurs can not be met - maybe the demerger should demerge the 
> entire cap?
>   
Possibly....
>> 5)
>> capabilities.xsd defines that <Cap> can have a <Type> child, and that
>> <Parameter> can have a <Type> child.
>> What is the purpose of this?
>>     
>
> This is also from SyncML Spec. maybe one day this could be handy for some 
> merger and demerge. The Type is something like chr, string or something like 
> that ...
>
> e.g. in SyncML say set for capability N (in case of a vcard, Name) Type to 
> "chr" ... which is character ... and some devices also set max and min ...
>
>   
>> I would expect that the type is defined by the format-plugin.
>>     
>
> Hmm, why? e.g. the vformat is very generic and can handle for example the 
> entire vcard spec ... now imagine that some devices has limited support for 
> the field TEL - e.g. only integers - no characters. But yeah that's just an 
> example i made up ... need to check for a better example which exist in the 
> real world.
>
>   
I still think the datatype should be defined by the format.
How can you have a format that says it wants parameter x as an integer, 
and a capability that says it can only handle x as a string?
If you want digits, no characters, and similar stuff, a regex would be 
better, I think.
>> 6)
>> capabilities.xsd defines that <Cap> can have <Min> and <Max> children.
>> I would like an example of how this would be used.
>>     
>
> Max number of characters for example ...
>
> For capability Name, only characters - but max are 32 characters.
>
> Again, this is from the SyncML capabilities definition (not quite sure if this 
> included also min or if i made this just up  ...)
>   
ACK
As far as I recall, SyncML just has "Size", ie. our "Max".
>> I.e.: Are there any conceivable format elements which have an unrestricted
>> range, or say a range of A-B, but where a plugin/member would only be able
>> to handle part of this range?
>>     
>
> Telephone numbers.
>
> Most devices only supported 0123456789 +#*pcw and so ... maybe some more ( ) 
> whitespace ... and some allow dashes - some not.
>
>   
This has nothing to do with min-max. This looks like a regex to me...
>> 7)
>> capabilities.xsd defines that <Cap> can have a <MaxOccurs> child.
>> Do we really expect demergers to handle this?
>>     
>
> I guess i added this also because it was part of the SyncML capabilities 
> definition. Real life Example:
>
> Only one Name field
> MaxOccurs of Telephone fields 3
>
> And yeah, we might want to handle this in demerge in the future. Imagine you 
> have a contact with 5 telephone numbers, but your mobile supports only up to 3 
> numbers. The mobile might would reject the entire contact if OpenSync would 
> try to send a contact with 5 numbers ... or even worse, it would tolerate this 
> and loose two telephone Numbers if this entry get synced back, due a change.
>
> So with the maxoccurs information we could merge back the 2 not-sync numbers 
> ...
>
> But we still need to solve the question which numbers should get synced ... 
> you could just sync the first 3 numbers in a contact. And prefer the numbers 
> which have the type preferred ...
>
>   
ACK
>> 8)
>> The current logic in _osync_obj_engine_mapping_find is:
>> Clone (i.e. make a complete copy of) change1. Demerge fields from the
>> clone which are not in caps2.
>> Clone (i.e. make a complete copy of) change2. Demerge fields from the
>> clone which are not in caps1.
>> Compare the two cloned objects.
>> To me this seems unnecessarily complicated and incurs a performance
>>  penalty. Why is this not implemented as a more "intelligent" compare
>>  function, which takes capabilities into account?
>>     
> [...]
>
> This is pretty new code and more or less just a proof of concept. If you came 
> up with a more efficient solution, let me know. This was the last thing i was 
> working on ... it's not completed.
>   
OK, let's continue this on a separate thread...
>
> Btw. do you want to specialize for the merger/demerger capabilities handling 
> in OpenSync? You already got a pretty good understanding how things tick ... 
> even if they don't tick as expected ;)
>   
I will try to contribute whenever and whereever I can - preferably 
without specialization!

/Henrik

Re: [Opensync-devel] Questions about capabilities

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

On Friday 23 October 2009 11:32:46 am he...@ka... wrote:
> 1)
> In capabilities.xsd we have an element called Parameter with
> maxOccurs="unbounded".
> In opensync_capability.h/c we have osync_capability_set_parameter whichs
> sets ONE parameter.
> As far as I can see, it sould be possible to have several parameters (such
> as both Location and Pref for an Address).
> So: is this a bug in the capabilities API (i.e. opensync_capability.h/c)?

Yes, that's a bug - we need to break the API for this ...


> 
> 2)
> A well-formed XML document must have exactlny one root node.
> According to capabilities.xsd the root node must be <Caps> which has an
> attribute called CapsFormat.
> If a plugin is offering capabilities in different CapsFormats (e.g.
> because it supports both vformat and xmlformat), how would this be
> specified?
> Suggestion: Rename <ObjType> to <ObjTypeCaps> and move the CapsFormat
> attribute from <Caps> to <ObjTypeCaps>.
> (API change probably needed as well).


This requires some more discussion i guess. Actually the capsformat is 
independent of the objformat .... i still need to describe how the capsformat 
thing works. I will go in more details in a separated mail about capsformat 
...

> 
> 3)
> capabilities.xsd defines that <Cap> can have a <DisplayName> child, and
> that <Parameter> can have a <DisplayName> child.
> When would we ever want to show an end-user the name of a capability or
> parameter?

Maybe thats useful to let user now which fields will be not synced and due to 
missing capabilities support - and will not get lost.

The idea of DisplayName comes from SyncML - SyncML spec has this defined. So 
some phones are providing this information .. so if this is available we might 
want to use this information on the first Sync or so to inform the users which 
fields will not appear on member X..


> 
> 4)
> capabilities.xsd defines that <Cap> can have a <MaxOccurs> child, but no
> <MinOccurs> child.
> Is this a mistake, or is it because the demerger would not be able to
> handle it anyway (i.e. what should the merger do if the change does not
> include the attribute for which MinOccurs > 0 ? )

We still can add this .. but first there needs to be a real use case in the 
"wild" ... This capabilities schema is based on the capabilities description 
from SyncML specs. AFAIK they haven't minoccurs either ...


Maybe if minoccurs can not be met - maybe the demerger should demerge the 
entire cap?

> 
> 5)
> capabilities.xsd defines that <Cap> can have a <Type> child, and that
> <Parameter> can have a <Type> child.
> What is the purpose of this?

This is also from SyncML Spec. maybe one day this could be handy for some 
merger and demerge. The Type is something like chr, string or something like 
that ...

e.g. in SyncML say set for capability N (in case of a vcard, Name) Type to 
"chr" ... which is character ... and some devices also set max and min ...

> I would expect that the type is defined by the format-plugin.

Hmm, why? e.g. the vformat is very generic and can handle for example the 
entire vcard spec ... now imagine that some devices has limited support for 
the field TEL - e.g. only integers - no characters. But yeah that's just an 
example i made up ... need to check for a better example which exist in the 
real world.

> 
> 6)
> capabilities.xsd defines that <Cap> can have <Min> and <Max> children.
> I would like an example of how this would be used.

Max number of characters for example ...

For capability Name, only characters - but max are 32 characters.

Again, this is from the SyncML capabilities definition (not quite sure if this 
included also min or if i made this just up  ...)

> I.e.: Are there any conceivable format elements which have an unrestricted
> range, or say a range of A-B, but where a plugin/member would only be able
> to handle part of this range?

Telephone numbers.

Most devices only supported 0123456789 +#*pcw and so ... maybe some more ( ) 
whitespace ... and some allow dashes - some not.


> 
> 7)
> capabilities.xsd defines that <Cap> can have a <MaxOccurs> child.
> Do we really expect demergers to handle this?

I guess i added this also because it was part of the SyncML capabilities 
definition. Real life Example:

Only one Name field
MaxOccurs of Telephone fields 3

And yeah, we might want to handle this in demerge in the future. Imagine you 
have a contact with 5 telephone numbers, but your mobile supports only up to 3 
numbers. The mobile might would reject the entire contact if OpenSync would 
try to send a contact with 5 numbers ... or even worse, it would tolerate this 
and loose two telephone Numbers if this entry get synced back, due a change.

So with the maxoccurs information we could merge back the 2 not-sync numbers 
...

But we still need to solve the question which numbers should get synced ... 
you could just sync the first 3 numbers in a contact. And prefer the numbers 
which have the type preferred ...

> 
> 8)
> The current logic in _osync_obj_engine_mapping_find is:
> Clone (i.e. make a complete copy of) change1. Demerge fields from the
> clone which are not in caps2.
> Clone (i.e. make a complete copy of) change2. Demerge fields from the
> clone which are not in caps1.
> Compare the two cloned objects.
> To me this seems unnecessarily complicated and incurs a performance
>  penalty. Why is this not implemented as a more "intelligent" compare
>  function, which takes capabilities into account?
[...]

This is pretty new code and more or less just a proof of concept. If you came 
up with a more efficient solution, let me know. This was the last thing i was 
working on ... it's not completed.


Btw. do you want to specialize for the merger/demerger capabilities handling 
in OpenSync? You already got a pretty good understanding how things tick ... 
even if they don't tick 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] An OpenSync process ???

[Henrik /K. <he...@ka...>]

Daniel Gollub wrote:
> On Friday 23 October 2009 09:05:24 pm Henrik /KaarPoSoft wrote:
>
> Please only write OpenSync application using the API.
>   
ACK.
>   
>> In a case like blueZync, it would be preferable if there was a running
>> instance of an osynctool-like process, which would accept messages on a
>> socket from blueZync to create a group, discover, sync, whatever.
>>     
>
> You mean something like a daemon?
>   
Yes!
> I also had this idea - but i'm not the person going to write that daemon. I 
> have enough responisbilities to complete the OpenSync API - which a daemon 
> could base on.
>
>   
ACK. But somebody else might write it...
>> This way blueZync - an extension to Mozilla Thunderbird - could be kept
>> a portable JavaScipt extension communicating with "the opensync process"
>> through sockets.
>> This way we would have no difficult-to-port C code in blueZync, and no
>> need for an end-user to install anything but a native OpenSync (with
>> this "new" process) and a platform-independent plugin to Thunderbird.
>>
>> Any comments on that?
>>
>> I am also thinking about dbus, but since I do not know the details of
>> dbus, I don't know if would be useful.
>> How about an OpenSync service on dbus ???
>>     
> [...]
>
> Yeah, i would also use D-Bus for that - i started with a Proof of concept 
> several years ago. But again, i'm going to concentrate on the OpenSync API 
> first.
>
> http://opensync.org/browser/branches/MobileStation?rev=2233
>
> I'm fine with the idea people using a Sync-daemon or write a standalone Sync-
> application - as long as it's based on OpenSync API ;)
>   
ACK.

/Henrik

Re: [Opensync-devel] Comments needed: mozilla-sync needs a redesign

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

On Friday 23 October 2009 08:25:29 pm Henrik /KaarPoSoft wrote:
> 2) Convince OpenSync to talk to this socket, instead of OpenSync's 
> normal sub-thread/sub-process
> 
> 
> I still have only limited knowledge of OpenSync, so I don't know:
> - how to convince OpenSync to talk to the Thunderbird socket, instead of 
> to an OpenSync plugin.
> - which messages in which format to send or receive
> - how to do this in Thunderbird
> 

OpenSync plugins can be written as a seperated process, which is already 
running. E.g. inside Mozilla. And communicate via FIFO

The plugin start-type is called OSYNC_START_TYPE_EXTERNAL - but AFAIK you 
still need to use the OpenSync API, for proper communcation via this socket.

The only existing plugin-code running as external i could found is inside some 
testcases:

tests/engine-tests/check_engine.c


-----8<-------
debug->plugin = osync_plugin_new(&error);
osync_plugin_set_name(debug->plugin, "mock-sync-foo");
osync_plugin_set_longname(debug->plugin, "Mock Sync Plugin");
osync_plugin_set_description(debug->plugin, "This is a pseudo plugin");
osync_plugin_set_start_type(debug->plugin, OSYNC_START_TYPE_EXTERNAL);
osync_plugin_set_config_type(debug->plugin, OSYNC_PLUGIN_NO_CONFIGURATION);


debug->client1 = osync_client_new(&error);
char *pipe_path = g_strdup_printf("%s/configs/group/1/pluginpipe", testbed);
osync_client_run_external(debug->client1, pipe_path, debug->plugin, &error);
---->8--------


Maybe this helps some how ... if you're interested in give this a try - let me 
know. So we can build up a proof of concept up. We need something like that 
anyway as reference implementation.

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] A more radical approach: Kill the mozilla-sync plugin ??

[Henrik /K. <he...@ka...>]

Thanks for your comments, Daniel!

Daniel Gollub wrote:
> On Saturday 24 October 2009 02:07:02 pm Henrik /KaarPoSoft wrote:
> [...]
>   
>> Following up on my earlier posts, here is my latest, crazy idea: Kill
>> the mozilla-sync plugin.
>>
>>
>> As mentioned before, the current design is flawed (using not-thread-safe
>> functions from Mozilla in threads), does not work with Thunderbird 3,
>> and is a nightmare to port between platforms - even between different
>> linux distros.
>>
>> Instead of using more development time on the mozilla-sync plugin,
>> syncing Mozilla could be accomplished by
>> - using the syncml-http-server plugin in OpenSync
>> - using the Funambol Thunderbird extension
>> (https://mozilla-plugin.forge.funambol.org/)
>>     
>
> How complicated would be the setup to get this kind of sync working?
>   
Well, I have verified that the two can talk in the first place.
Since they are both SyncML it "should" work, so I hope fixing the 
problems should not be too difficult.
> I wonder if this would allow kind of a out-of-the box setup?
>   
run osynctool
launch mozilla
press funambol button in mozilla.
(However, a better GUI would be needed - see below)
> When Armin and others decided to implement a IPC system in OpenSync they also 
> introduced this three  "ProcessStartTypes" for plugin:
>
>  - thread (default)
>  - process (fork - runs in the osplugin wrappe process)
>  - external (communication via FIFO)
>
> The later one was iirc the idea to be used for applications like thunderbird 
> or mozilla, which didn't provide any public API or easy to handle API to sync.
>
> so if the funambol thunderbird extension doesn't work out ... whabt about 
> writing an "OpenSync extension" for thunderbird?
>
> This extension is more or less a OpenSync plugin living inside this extension. 
> This extension would then communicate with the OpenSync framework via a fifo 
> ... ipc/fifo setup is all handled by the OpenSync API - AFAIK.
>   
Yes, that is certainly also something I was thinking about.
> Unfortuantely there is no real-life example yet, but the code for those 
> external plugins exists. Need to check if i can make up an example out of 
> testcases ...
>   
The lack of documentation/example is one of the things holding me back 
from this approach.
> Or would this be no option for you?
> I could imagine something like this would allow simpler setup ... since you 
> don't have to setup things like an local IP connection or so. For an regular 
> users this would be a bit confusing to configure a "network" connection to 
> talk to a local running application - right?
>   
Technically this is no problem. syncml-http-server and Funambol handles 
this already.
>   
>> Then there is the question of GUI...
>>
>> blueZync is a GUI for OpenSync in Mozilla.
>> It does not suffer from the mozilla-sync design flaw or Thunderbird 3
>> incompatibility, but is still difficult to port, and not really
>> satisfactory.
>> I am thinking about killing this one as well, and maybe work on a GTK+
>> replacement for kitchensync.
>>     
>
> Acutally you would work on a replacement of MultiSync-0.90 - which is a 
> OpenSync GTK gui .. currently AFAIK unmaintined.
>
> There is also gnome-sync-tool you might want to have a look at.
>   
I never used any of those tools. But I will have a look.
> [...]
> You don't have to use KitchenSync as _the_ ideal OpenSync GUI. You could also 
> write some Mozilla plugin(s) which just setup a sync with dedicated plugins - 
> e.g. Mobile-Sync-Plugin for Mozilla
>
> Which provides a very simple UI to setup a group of a mozilla-plugin and the 
> syncml-obex-client and maybe some other (synce, gnokii-sync, ...) just 
> dedicated for mobile syncing ... so you don't have to write a UI to create 
> generic groups for all available plugins and so.
>
> Just an UI which provides a search-bluetooth-device UI or so and setups a 
> group with the best fitting plugin on the fly. But the end-user doesn't see 
> anything that there got a group with member created - your app doesn't need to 
> support multiple groups and so ...
>
>   
This is exactly what blueZync is doing today.
Even with multiple groups and generic plugin handling.

But the problem is that I have to drag along a complicated XPCOM C++ 
interface to call the OpenSync functions and receive the callbacks.
It kind-of works today, but it is not nice, and not easily portable 
(actually, it IS portable, but getting the prerequisites (Mozilla SDK 
etc) in place is a mess.

/Henrik

Re: [Opensync-devel] An OpenSync process ???

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

On Friday 23 October 2009 09:05:24 pm Henrik /KaarPoSoft wrote:
> Currently there seems to be two ways if you want to be the master of
> OpenSync synchronization:
> 
> (1) Use osynctool
> (2) Implement your own master which would call
> osync_engine_synchronize_and_block (after some
> osync_engine_set_XXX_callback calls).

JFYI, osynctool is just an implementation reference. In long-term i don't want 
to see any application being dependend on osynctool. Also i don't want to see 
any non-developer using osynctool.

Please only write OpenSync application using the API.

> 
> In a case like blueZync, it would be preferable if there was a running
> instance of an osynctool-like process, which would accept messages on a
> socket from blueZync to create a group, discover, sync, whatever.

You mean something like a daemon?
I also had this idea - but i'm not the person going to write that daemon. I 
have enough responisbilities to complete the OpenSync API - which a daemon 
could base on.

> 
> This way blueZync - an extension to Mozilla Thunderbird - could be kept
> a portable JavaScipt extension communicating with "the opensync process"
> through sockets.
> This way we would have no difficult-to-port C code in blueZync, and no
> need for an end-user to install anything but a native OpenSync (with
> this "new" process) and a platform-independent plugin to Thunderbird.
> 
> Any comments on that?
> 
> I am also thinking about dbus, but since I do not know the details of
> dbus, I don't know if would be useful.
> How about an OpenSync service on dbus ???
[...]

Yeah, i would also use D-Bus for that - i started with a Proof of concept 
several years ago. But again, i'm going to concentrate on the OpenSync API 
first.

http://opensync.org/browser/branches/MobileStation?rev=2233

I'm fine with the idea people using a Sync-daemon or write a standalone Sync-
application - as long as it's based on OpenSync API ;)

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] A more radical approach: Kill the mozilla-sync plugin ??

[Henrik /K. <he...@ka...>]

Dear all,


Following up on my earlier posts, here is my latest, crazy idea: Kill 
the mozilla-sync plugin.


As mentioned before, the current design is flawed (using not-thread-safe 
functions from Mozilla in threads), does not work with Thunderbird 3, 
and is a nightmare to port between platforms - even between different 
linux distros.

Instead of using more development time on the mozilla-sync plugin, 
syncing Mozilla could be accomplished by
- using the syncml-http-server plugin in OpenSync
- using the Funambol Thunderbird extension 
(https://mozilla-plugin.forge.funambol.org/)

I tried this setup, and the Funambol extension is able to communicate 
with the syncml-http-server.
However, the sync fails, so there is more work to be done here...
Further, the Funambol extension does not work with Thunderbird 3, and it 
is unclear if work is ongoing to address this.

But I am starting to think that time may be better spend on fixing the 
OpenSync core, syncml-http-server and/or Funambol than re-designing and 
re-implementing mozilla-sync.


Then there is the question of GUI...

blueZync is a GUI for OpenSync in Mozilla.
It does not suffer from the mozilla-sync design flaw or Thunderbird 3 
incompatibility, but is still difficult to port, and not really 
satisfactory.
I am thinking about killing this one as well, and maybe work on a GTK+ 
replacement for kitchensync.
Maybe this GUI could even be launched from within Mozilla with a small 
plugin.


Your comments and thoughts about the above would be much appreciated.

/Henrik

[Opensync-devel] An OpenSync process ???

[Henrik /K. <he...@ka...>]

Currently there seems to be two ways if you want to be the master of 
OpenSync synchronization:

(1) Use osynctool
(2) Implement your own master which would call 
osync_engine_synchronize_and_block (after some 
osync_engine_set_XXX_callback calls).

In a case like blueZync, it would be preferable if there was a running 
instance of an osynctool-like process, which would accept messages on a 
socket from blueZync to create a group, discover, sync, whatever.

This way blueZync - an extension to Mozilla Thunderbird - could be kept 
a portable JavaScipt extension communicating with "the opensync process" 
through sockets.
This way we would have no difficult-to-port C code in blueZync, and no 
need for an end-user to install anything but a native OpenSync (with 
this "new" process) and a platform-independent plugin to Thunderbird.

Any comments on that?

I am also thinking about dbus, but since I do not know the details of 
dbus, I don't know if would be useful.
How about an OpenSync service on dbus ???

/Henrik

Re: [Opensync-devel] [RFC] Break API: change long to long long?

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

On Thu, Oct 22, 2009 at 10:47:25PM +0200, Daniel Gollub wrote:
> On Thursday 22 October 2009 10:49:54 am Henrik /KaarPoSoft wrote:
> > In my opinion the best solution would to break API and change long long 
> > to long.
> > 
> 
> Are there any vetos?
> Could someone prepare a patch?

Since I brought this up, I can prepare a patch.  Busy weekend here though,
so please pardon any slight delay.

Thanks,
- Chris

[Opensync-devel] Comments needed: mozilla-sync needs a redesign

[Henrik /K. <he...@ka...>]

mozilla-sync needs a redesign.


Currently, mozilla-sync is a threaded plugin to OpenSync.

It will initialize a private instance of XPCOM and access address-books 
etc. as it works as an OpenSync plugin.

Now, this approach is broken by design, since the 
Mozilla/Thunderbird/XPCOM functions are not thread safe.

If the Thunderbird GUI is running in another process, all kinds of 
disasters may happen because of the lack of thead/process safety.

Even worse: the blueZync GUI (an extension to Thunderbird) runs OpenSync 
(in it's own thread) so here, for sure, we have a problem due to the 
lack of thead/process safety.


One possible solution would be to implement some process/thread in 
Thunderbird to listen for custom messages from a modified version of 
mozilla-sync.

I.e. to keep the mozilla-sync threaded, but instead of letting it access 
XPCOM data directly, it would implement some proprietary protocol to 
talk to a proprietary listener in  Thunderbird.

This seems to be an unnecessary complication, as OpenSync already has 
process communication capabilities.


So here is my current idea:

1) Create a listening socket in a running Thunderbird GUI. This socket 
would listen for OpenSync messages, and act accordingly.

2) Convince OpenSync to talk to this socket, instead of OpenSync's 
normal sub-thread/sub-process


I still have only limited knowledge of OpenSync, so I don't know:
- how to convince OpenSync to talk to the Thunderbird socket, instead of 
to an OpenSync plugin.
- which messages in which format to send or receive
- how to do this in Thunderbird


Any comments / help / hints / etc on this would be most appreciated.


/Henrik

[Opensync-devel] Questions about capabilities - again

[Henrik /K. <he...@ka...>]

I am not sure if this ever reached the list.
Apologies if you get it twice

1)
In capabilities.xsd we have an element called Parameter with
maxOccurs="unbounded".
In opensync_capability.h/c we have osync_capability_set_parameter whichs
sets ONE parameter.
As far as I can see, it sould be possible to have several parameters (such
as both Location and Pref for an Address).
So: is this a bug in the capabilities API (i.e. opensync_capability.h/c)?

2)
A well-formed XML document must have exactly one root node.
According to capabilities.xsd the root node must be <Caps> which has an
attribute called CapsFormat.
If a plugin is offering capabilities in different CapsFormats (e.g.
because it supports both vformat and xmlformat), how would this be
specified?
Suggestion: Rename <ObjType> to <ObjTypeCaps> and move the CapsFormat
attribute from <Caps> to <ObjTypeCaps>.
(API change probably needed as well).

3)
capabilities.xsd defines that <Cap> can have a <DisplayName> child, and
that <Parameter> can have a <DisplayName> child.
When would we ever want to show an end-user the name of a capability or
parameter?

4)
capabilities.xsd defines that <Cap> can have a <MaxOccurs> child, but no
<MinOccurs> child.
Is this a mistake, or is it because the demerger would not be able to
handle it anyway (i.e. what should the merger do if the change does not
include the attribute for which MinOccurs > 0 ? )

5)
capabilities.xsd defines that <Cap> can have a <Type> child, and that
<Parameter> can have a <Type> child.
What is the purpose of this?
I would expect that the type is defined by the format-plugin.

6)
capabilities.xsd defines that <Cap> can have <Min> and <Max> children.
I would like an example of how this would be used.
I.e.: Are there any conceivable format elements which have an unrestricted
range, or say a range of A-B, but where a plugin/member would only be able
to handle part of this range?

7)
capabilities.xsd defines that <Cap> can have a <MaxOccurs> child.
Do we really expect demergers to handle this?

8)
The current logic in _osync_obj_engine_mapping_find is:
Clone (i.e. make a complete copy of) change1. Demerge fields from the
clone which are not in caps2.
Clone (i.e. make a complete copy of) change2. Demerge fields from the
clone which are not in caps1.
Compare the two cloned objects.
To me this seems unnecessarily complicated and incurs a performance penalty.
Why is this not implemented as a more "intelligent" compare function,
which takes capabilities into account?

/Henrik

Re: [Opensync-devel] vcard standardization (was: Re: Getting things back on track)

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

On Fri, 2009-10-23 at 07:13 +0200, Patrick Ohly wrote:
> On Wed, 2009-10-21 at 01:12 -0400, Martin Owens wrote:
> > output clean FreeDesktop.org or LSB vcards
> 
> Have these two bodies standardized extensions to vCard 2.1/3.0? Do you
> have a pointer to that?
> 

As far as I know they haven't, wouldn't it be nice if they had though.

Forgive me if I made it sound like they had already, some of these
problems are standards problems and can only really be solved with RFC
or similar in the right bodies.

Martin,

[Opensync-devel] Questions about capabilities

[<he...@ka...>]

1)
In capabilities.xsd we have an element called Parameter with
maxOccurs="unbounded".
In opensync_capability.h/c we have osync_capability_set_parameter whichs
sets ONE parameter.
As far as I can see, it sould be possible to have several parameters (such
as both Location and Pref for an Address).
So: is this a bug in the capabilities API (i.e. opensync_capability.h/c)?

2)
A well-formed XML document must have exactly one root node.
According to capabilities.xsd the root node must be <Caps> which has an
attribute called CapsFormat.
If a plugin is offering capabilities in different CapsFormats (e.g.
because it supports both vformat and xmlformat), how would this be
specified?
Suggestion: Rename <ObjType> to <ObjTypeCaps> and move the CapsFormat
attribute from <Caps> to <ObjTypeCaps>.
(API change probably needed as well).

3)
capabilities.xsd defines that <Cap> can have a <DisplayName> child, and
that <Parameter> can have a <DisplayName> child.
When would we ever want to show an end-user the name of a capability or
parameter?

4)
capabilities.xsd defines that <Cap> can have a <MaxOccurs> child, but no
<MinOccurs> child.
Is this a mistake, or is it because the demerger would not be able to
handle it anyway (i.e. what should the merger do if the change does not
include the attribute for which MinOccurs > 0 ? )

5)
capabilities.xsd defines that <Cap> can have a <Type> child, and that
<Parameter> can have a <Type> child.
What is the purpose of this?
I would expect that the type is defined by the format-plugin.

6)
capabilities.xsd defines that <Cap> can have <Min> and <Max> children.
I would like an example of how this would be used.
I.e.: Are there any conceivable format elements which have an unrestricted
range, or say a range of A-B, but where a plugin/member would only be able
to handle part of this range?

7)
capabilities.xsd defines that <Cap> can have a <MaxOccurs> child.
Do we really expect demergers to handle this?

8)
The current logic in _osync_obj_engine_mapping_find is:
Clone (i.e. make a complete copy of) change1. Demerge fields from the
clone which are not in caps2.
Clone (i.e. make a complete copy of) change2. Demerge fields from the
clone which are not in caps1.
Compare the two cloned objects.
To me this seems unnecessarily complicated and incurs a performance penalty.
Why is this not implemented as a more "intelligent" compare function,
which takes capabilities into account?

/Henrik

[Opensync-devel] vcard standardization (was: Re: Getting things back on track)

[Patrick O. <pat...@gm...>]

On Wed, 2009-10-21 at 01:12 -0400, Martin Owens wrote:
> output clean FreeDesktop.org or LSB vcards

Have these two bodies standardized extensions to vCard 2.1/3.0? Do you
have a pointer to that?

-- 
Bye, Patrick Ohly
--  
Pat...@gm...
http://www.estamos.de/

Re: [Opensync-devel] discover + sync = crash

[Ian M. <ian...@ca...>]

2009/10/22 Chris Frey <cd...@fo...>:
> Here are the backtraces of all threads:  (crashed thread is at the end)

> (gdb) thread 31
> [Switching to thread 31 (Thread 0xb25ffb90 (LWP 25739))]#0  0xb7bb98f0 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
> (gdb) bt
> #0  0xb7bb98f0 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
> #1  0xb7ecea9d in pthread_cond_wait () from /lib/libc.so.6
> #2  0xb7754c24 in giop_recv_buffer_get () from /usr/lib/libORBit-2.so.0
> #3  0xb7759618 in ORBit_small_invoke_stub () from /usr/lib/libORBit-2.so.0
> #4  0xb7759825 in ORBit_small_invoke_stub_n () from /usr/lib/libORBit-2.so.0
> #5  0xb7765fc2 in ORBit_c_stub_invoke () from /usr/lib/libORBit-2.so.0
> #6  0xb767e65f in GNOME_Evolution_Calendar_CalFactory_getCal (_obj=0xb3600a50,
>    source=0xb3600b30 "<?xml version=\"1.0\"?>\n<source uid=\"1256244172.25695.5@frontdesk\" name=\"\" uri=\"file:///home/tarball/.evolution/calendar/local/system\"/>\n", type=1, listener=0x848e6b0, ev=0xb25ff038)
>    at Evolution-DataServer-Calendar-stubs.c:426
> #7  0xb7682022 in e_cal_new (source=0x834c420, type=E_CAL_SOURCE_TYPE_EVENT)
>    at e-cal.c:1296
> #8  0xb7682330 in e_cal_new_from_uri (
>    uri=0x8482f68 "file:///home/tarball/.evolution/calendar/local/system",
>    type=E_CAL_SOURCE_TYPE_EVENT) at e-cal.c:1449
> #9  0xb76824dd in e_cal_new_system_calendar () at e-cal.c:1478
> #10 0xb768b36d in e_cal_open_default (ecal=0xb25ff10c,
>    type=E_CAL_SOURCE_TYPE_EVENT, func=0, data=0x0, error=0xb25ff108)
>    at e-cal.c:5135
> #11 0xb79c73bb in evo2_ecal_open_cal (path=0x84796e0 "default",
>    source_type=E_CAL_SOURCE_TYPE_EVENT, error=0xb25ff144)
>    at /home/cdfrey/software/opensync/git/plugins/evolution2/src/evolution2_ecal.c:67
> #12 0xb79c7509 in evo2_ecal_connect (sink=0x83f3648, info=0x83fd338,
>    ctx=0x8482d30, userdata=0x83b6890)
>    at /home/cdfrey/software/opensync/git/plugins/evolution2/src/evolution2_ecal.c:91
> #13 0xb806ca1f in osync_objtype_sink_connect (sink=0x83f3648, info=0x83fd338,
>    ctx=0x8482d30)
>    at /home/cdfrey/software/opensync/git/opensync/opensync/plugin/opensync_objtype_sink.c:327
> #14 0xb80235cb in _osync_client_handle_connect (client=0x8354148,
>    message=0x84796b8, error=0xb25ff224)
>    at /home/cdfrey/software/opensync/git/opensync/opensync/client/opensync_client.c:1050
> #15 0xb80248cf in _osync_client_message_handler (message=0x84796b8,
>    user_data=0x8354148)
>    at /home/cdfrey/software/opensync/git/opensync/opensync/client/opensync_client.c:1514
> #16 0xb8057c3d in _incoming_dispatch (source=0x8354960, callback=0,
>    user_data=0x8353fc8)
>    at /home/cdfrey/software/opensync/git/opensync/opensync/ipc/opensync_queue.c:391
> #17 0xb7f701d8 in IA__g_main_context_dispatch (context=0x8354db8)
>    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gmain.c:2012
> #18 0xb7f73873 in g_main_context_iterate (context=0x8354db8, block=1,
>    dispatch=1, self=0x83580c0)
>    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gmain.c:2645
> #19 0xb7f73d92 in IA__g_main_loop_run (loop=0x8357bf0)
>    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gmain.c:2853
> #20 0xb7f9a16f in g_thread_create_proxy (data=0x83580c0)
> ---Type <return> to continue, or q <return> to quit---
>    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gthread.c:635
> #21 0xb7bb5f3b in start_thread () from /lib/libpthread.so.0
> #22 0xb7ec2bee in clone () from /lib/libc.so.6
>

It seems the calls to e_cal_open_default triggers the crash on the
second creation of an osync_engine

Setting the evo2sync plugin to run as a process not a thread fixes the
segfault.  I'm not sure what is causing this though - something to do
with the loading /unloading of evo2sync on engine creation destruction

Patch attached for you to try

Running as a process seems to cause some problems with queue timeouts.

Ian

Re: [Opensync-devel] discover + sync = crash

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

Here are the backtraces of all threads:  (crashed thread is at the end)

- Chris



(gdb) info threads 
* 34 Thread 0xb0dffb90 (LWP 25744)  0x00000000 in ?? ()
  33 Thread 0xb15ffb90 (LWP 25741)  0xb7eb950d in poll () from /lib/libc.so.6
  32 Thread 0xb1dffb90 (LWP 25740)  0xb7eb950d in poll () from /lib/libc.so.6
  31 Thread 0xb25ffb90 (LWP 25739)  0xb7bb98f0 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
  30 Thread 0xb2dffb90 (LWP 25738)  0xb7eb950d in poll () from /lib/libc.so.6
  29 Thread 0xb6048b90 (LWP 25737)  0xb7eb950d in poll () from /lib/libc.so.6
  28 Thread 0xb7048b90 (LWP 25736)  0xb7eb950d in poll () from /lib/libc.so.6
  27 Thread 0xb5848b90 (LWP 25735)  0xb7eb950d in poll () from /lib/libc.so.6
  26 Thread 0xb4848b90 (LWP 25734)  0xb7eb3781 in open () from /lib/libc.so.6
  25 Thread 0xb5048b90 (LWP 25733)  0xb7eb950d in poll () from /lib/libc.so.6
  24 Thread 0xb6848b90 (LWP 25732)  0xb7eb950d in poll () from /lib/libc.so.6
  23 Thread 0xb35ffb90 (LWP 25731)  IA__g_vasprintf (string=0xb35fefa4, 
    format=0xb80770bf "%s%cThread%lu-%i.log", args=0xb35fefb4 "|\031\212¿/")
    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gprintf.c:301
  19 Thread 0xb3815b90 (LWP 25725)  0xb7bbc2c7 in __lll_unlock_wake ()
   from /lib/libpthread.so.0
  18 Thread 0xb4015b90 (LWP 25716)  0xb7eb950d in poll () from /lib/libc.so.6
  1 Thread 0xb7b066b0 (LWP 25695)  0xb7bb98f0 in pthread_cond_wait@@GLIBC_2.3.2
    () from /lib/libpthread.so.0


(gdb) thread 1
[Switching to thread 1 (Thread 0xb7b066b0 (LWP 25695))]#0  0xb7bb98f0 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
(gdb) bt
#0  0xb7bb98f0 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#1  0xb7ecea9d in pthread_cond_wait () from /lib/libc.so.6
#2  0xb8038400 in osync_engine_synchronize_and_block (engine=0x8142de0, 
    error=0xbf8a0d74)
    at /home/cdfrey/software/opensync/git/opensync/opensync/engine/opensync_engine.c:2158
#3  0x0804cfab in osynctool_synchronize (env=0x8055328, 
    groupname=0xbf8a1932 "ostest_trial_group", wait=0, multi=0, objtypes=0x0, 
    error=0xbf8a0d74)
    at /home/cdfrey/software/opensync/git/osynctool/tools/osynctool.c:685
#4  0x0804f88e in main (argc=3, argv=0xbf8a0e44)
    at /home/cdfrey/software/opensync/git/osynctool/tools/osynctool.c:1657


(gdb) thread 18
[Switching to thread 18 (Thread 0xb4015b90 (LWP 25716))]#0  0xb7eb950d in poll
    () from /lib/libc.so.6
(gdb) bt
#0  0xb7eb950d in poll () from /lib/libc.so.6
#1  0xb7f73702 in g_main_context_iterate (context=0x81b0e78, block=1, 
    dispatch=1, self=0x81b1c98)
    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gmain.c:2954
#2  0xb7f73d92 in IA__g_main_loop_run (loop=0x81b1e20)
    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gmain.c:2853
#3  0xb786d8b2 in startup_mainloop (arg=0x0) at e-book.c:3773
#4  0xb7f9a16f in g_thread_create_proxy (data=0x81b1c98)
    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gthread.c:635
#5  0xb7bb5f3b in start_thread () from /lib/libpthread.so.0
#6  0xb7ec2bee in clone () from /lib/libc.so.6


(gdb) thread 19
[Switching to thread 19 (Thread 0xb3815b90 (LWP 25725))]#0  0xb7bbc2c7 in __lll_unlock_wake () from /lib/libpthread.so.0
(gdb) bt
#0  0xb7bbc2c7 in __lll_unlock_wake () from /lib/libpthread.so.0
#1  0xb7bb8d3b in _L_unlock_92 () from /lib/libpthread.so.0
#2  0xb7bb897c in __pthread_mutex_unlock_usercnt () from /lib/libpthread.so.0
#3  0xb7ececa6 in pthread_mutex_unlock () from /lib/libc.so.6
#4  0xb7f49c06 in IA__g_async_queue_unlock (queue=0x1)
    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gasyncqueue.c:208
#5  0xb77528ed in giop_thread_request_push_key () from /usr/lib/libORBit-2.so.0
#6  0xb77694dd in ?? () from /usr/lib/libORBit-2.so.0
#7  0x00000000 in ?? ()


(gdb) thread 23
[Switching to thread 23 (Thread 0xb35ffb90 (LWP 25731))]#0  IA__g_vasprintf (
    string=0xb35fefa4, format=0xb80770bf "%s%cThread%lu-%i.log", 
    args=0xb35fefb4 "|\031\212¿/")
    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gprintf.c:301
301     /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gprintf.c: No such file or directory.
        in /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gprintf.c
(gdb) bt
#0  IA__g_vasprintf (string=0xb35fefa4, 
    format=0xb80770bf "%s%cThread%lu-%i.log", args=0xb35fefb4 "|\031\212¿/")
    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gprintf.c:301
#1  0xb7f925d6 in IA__g_strdup_printf (
    format=0xb80770bf "%s%cThread%lu-%i.log")
    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gstrfuncs.c:218
#2  0xb8031e3e in osync_trace (type=TRACE_EXIT, 
    message=0xb8076ef6 "%s: table \"%s\" exists.")
    at /home/cdfrey/software/opensync/git/opensync/opensync/debug/opensync_trace.c:153
#3  0xb80311cb in osync_db_table_exists (db=0x8062ff8, 
    tablename=0xb807287e "tbl_changes", error=0xb35ff240)
    at /home/cdfrey/software/opensync/git/opensync/opensync/db/opensync_db.c:373
#4  0xb801c1aa in osync_archive_create_changes (db=0x8062ff8, 
    objtype=0x843c970 "note", error=0xb35ff240)
    at /home/cdfrey/software/opensync/git/opensync/opensync/archive/opensync_archive.c:44
#5  0xb801d708 in osync_archive_load_changes (archive=0x8295948, 
    objtype=0x843c970 "note", ids=0xb35ff170, uids=0xb35ff174, 
    mappingids=0xb35ff16c, memberids=0xb35ff168, error=0xb35ff240)
    at /home/cdfrey/software/opensync/git/opensync/opensync/archive/opensync_archive.c:387
#6  0xb805eeb4 in osync_mapping_table_load (table=0x8436580, 
    archive=0x8295948, objtype=0x843c970 "note", error=0xb35ff240)
    at /home/cdfrey/software/opensync/git/opensync/opensync/mapping/opensync_mapping_table.c:83
#7  0xb803eb6c in osync_obj_engine_initialize (engine=0x843c908, 
    error=0xb35ff240)
    at /home/cdfrey/software/opensync/git/opensync/opensync/engine/opensync_obj_engine.c:966
#8  0xb80375a5 in osync_engine_command (engine=0x8142de0, command=0x835c680)
    at /home/cdfrey/software/opensync/git/opensync/opensync/engine/opensync_engine.c:1797
#9  0xb8033085 in _command_dispatch (source=0x81bda98, callback=0, 
    user_data=0x8142de0)
    at /home/cdfrey/software/opensync/git/opensync/opensync/engine/opensync_engine.c:365
#10 0xb7f701d8 in IA__g_main_context_dispatch (context=0x820f740)
    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gmain.c:2012
#11 0xb7f73873 in g_main_context_iterate (context=0x820f740, block=1, 
    dispatch=1, self=0x81e09d8)
    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gmain.c:2645
#12 0xb7f73d92 in IA__g_main_loop_run (loop=0x81c58a0)
    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gmain.c:2853
#13 0xb7f9a16f in g_thread_create_proxy (data=0x81e09d8)
    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gthread.c:635
#14 0xb7bb5f3b in start_thread () from /lib/libpthread.so.0
#15 0xb7ec2bee in clone () from /lib/libc.so.6


(gdb) thread 24
[Switching to thread 24 (Thread 0xb6848b90 (LWP 25732))]#0  0xb7eb950d in poll
    () from /lib/libc.so.6
(gdb) bt
#0  0xb7eb950d in poll () from /lib/libc.so.6
#1  0xb7f73702 in g_main_context_iterate (context=0x8186e50, block=1, 
    dispatch=1, self=0x82b5a38)
    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gmain.c:2954
#2  0xb7f73d92 in IA__g_main_loop_run (loop=0x81df908)
    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gmain.c:2853
#3  0xb7f9a16f in g_thread_create_proxy (data=0x82b5a38)
    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gthread.c:635
#4  0xb7bb5f3b in start_thread () from /lib/libpthread.so.0
#5  0xb7ec2bee in clone () from /lib/libc.so.6


(gdb) thread 25
[Switching to thread 25 (Thread 0xb5048b90 (LWP 25733))]#0  0xb7eb950d in poll
    () from /lib/libc.so.6
(gdb) bt
#0  0xb7eb950d in poll () from /lib/libc.so.6
#1  0xb7f73702 in g_main_context_iterate (context=0x81df708, block=1, 
    dispatch=1, self=0x82b42b0)
    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gmain.c:2954
#2  0xb7f73d92 in IA__g_main_loop_run (loop=0x816d290)
    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gmain.c:2853
#3  0xb7f9a16f in g_thread_create_proxy (data=0x82b42b0)
    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gthread.c:635
#4  0xb7bb5f3b in start_thread () from /lib/libpthread.so.0
#5  0xb7ec2bee in clone () from /lib/libc.so.6


(gdb) thread 26
[Switching to thread 26 (Thread 0xb4848b90 (LWP 25734))]#0  0xb7eb3781 in open
    () from /lib/libc.so.6
(gdb) bt
#0  0xb7eb3781 in open () from /lib/libc.so.6
#1  0xb78ae1f0 in usb_os_find_devices () from /lib/libusb-0.1.so.4
#2  0xb78ab892 in usb_find_devices () from /lib/libusb-0.1.so.4
#3  0xb7a17e27 in Match (this=0xb4848070, vendor=4042, product=1, busname=0x0, 
    devname=0x0) at usbwrap.cc:84
#4  0xb7a2141d in Barry::Probe::ProbeMatching (this=0xb4848114, vendor=4042, 
    product=1, busname=0x0, devname=0x0) at probe.cc:165
#5  0xb7a2166e in Probe (this=0xb4848114, busname=0x0, devname=0x0, epp=0x0)
    at probe.cc:141
#6  0xb7aaf6ac in connect (sink=0x8244200, info=0x8229608, ctx=0x84826a8, 
    userdata=0x8246808) at barry_sync.cc:699
#7  0xb806ca1f in osync_objtype_sink_connect (sink=0x8244200, info=0x8229608, 
    ctx=0x84826a8)
    at /home/cdfrey/software/opensync/git/opensync/opensync/plugin/opensync_objtype_sink.c:327
#8  0xb80235cb in _osync_client_handle_connect (client=0x81df470, 
    message=0x8482be8, error=0xb4848224)
    at /home/cdfrey/software/opensync/git/opensync/opensync/client/opensync_client.c:1050
#9  0xb80248cf in _osync_client_message_handler (message=0x8482be8, 
    user_data=0x81df470)
    at /home/cdfrey/software/opensync/git/opensync/opensync/client/opensync_client.c:1514
#10 0xb8057c3d in _incoming_dispatch (source=0x82b3d18, callback=0, 
    user_data=0x81df390)
    at /home/cdfrey/software/opensync/git/opensync/opensync/ipc/opensync_queue.c:391
#11 0xb7f701d8 in IA__g_main_context_dispatch (context=0x81df4f0)
    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gmain.c:2012
#12 0xb7f73873 in g_main_context_iterate (context=0x81df4f0, block=1, 
    dispatch=1, self=0x82b2fb8)
    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gmain.c:2645
#13 0xb7f73d92 in IA__g_main_loop_run (loop=0x81df570)
    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gmain.c:2853
#14 0xb7f9a16f in g_thread_create_proxy (data=0x82b2fb8)
    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gthread.c:635
#15 0xb7bb5f3b in start_thread () from /lib/libpthread.so.0
#16 0xb7ec2bee in clone () from /lib/libc.so.6


(gdb) thread 27
[Switching to thread 27 (Thread 0xb5848b90 (LWP 25735))]#0  0xb7eb950d in poll
    () from /lib/libc.so.6
(gdb) bt
#0  0xb7eb950d in poll () from /lib/libc.so.6
#1  0xb7f73702 in g_main_context_iterate (context=0x81e0880, block=1, 
    dispatch=1, self=0x82ce600)
    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gmain.c:2954
#2  0xb7f73d92 in IA__g_main_loop_run (loop=0x8286d70)
    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gmain.c:2853
#3  0xb7f9a16f in g_thread_create_proxy (data=0x82ce600)
    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gthread.c:635
#4  0xb7bb5f3b in start_thread () from /lib/libpthread.so.0
#5  0xb7ec2bee in clone () from /lib/libc.so.6


(gdb) thread 28
[Switching to thread 28 (Thread 0xb7048b90 (LWP 25736))]#0  0xb7eb950d in poll
    () from /lib/libc.so.6
(gdb) bt
#0  0xb7eb950d in poll () from /lib/libc.so.6
#1  0xb7f73702 in g_main_context_iterate (context=0x81e0090, block=1, 
    dispatch=1, self=0x82cc9e8)
    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gmain.c:2954
#2  0xb7f73d92 in IA__g_main_loop_run (loop=0x816d118)
    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gmain.c:2853
#3  0xb7f9a16f in g_thread_create_proxy (data=0x82cc9e8)
    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gthread.c:635
#4  0xb7bb5f3b in start_thread () from /lib/libpthread.so.0
#5  0xb7ec2bee in clone () from /lib/libc.so.6


(gdb) thread 29
[Switching to thread 29 (Thread 0xb6048b90 (LWP 25737))]#0  0xb7eb950d in poll
    () from /lib/libc.so.6
(gdb) bt
#0  0xb7eb950d in poll () from /lib/libc.so.6
#1  0xb7f73702 in g_main_context_iterate (context=0x83571c8, block=1, 
    dispatch=1, self=0x8354708)
    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gmain.c:2954
#2  0xb7f73d92 in IA__g_main_loop_run (loop=0x82cd418)
    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gmain.c:2853
#3  0xb7f9a16f in g_thread_create_proxy (data=0x8354708)
    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gthread.c:635
#4  0xb7bb5f3b in start_thread () from /lib/libpthread.so.0
#5  0xb7ec2bee in clone () from /lib/libc.so.6


(gdb) thread 30
[Switching to thread 30 (Thread 0xb2dffb90 (LWP 25738))]#0  0xb7eb950d in poll
    () from /lib/libc.so.6
(gdb) bt
#0  0xb7eb950d in poll () from /lib/libc.so.6
#1  0xb7f73702 in g_main_context_iterate (context=0x8354c70, block=1, 
    dispatch=1, self=0x8356d80)
    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gmain.c:2954
#2  0xb7f73d92 in IA__g_main_loop_run (loop=0x83546f8)
    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gmain.c:2853
#3  0xb7f9a16f in g_thread_create_proxy (data=0x8356d80)
    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gthread.c:635
#4  0xb7bb5f3b in start_thread () from /lib/libpthread.so.0
#5  0xb7ec2bee in clone () from /lib/libc.so.6


(gdb) thread 31
[Switching to thread 31 (Thread 0xb25ffb90 (LWP 25739))]#0  0xb7bb98f0 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
(gdb) bt
#0  0xb7bb98f0 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#1  0xb7ecea9d in pthread_cond_wait () from /lib/libc.so.6
#2  0xb7754c24 in giop_recv_buffer_get () from /usr/lib/libORBit-2.so.0
#3  0xb7759618 in ORBit_small_invoke_stub () from /usr/lib/libORBit-2.so.0
#4  0xb7759825 in ORBit_small_invoke_stub_n () from /usr/lib/libORBit-2.so.0
#5  0xb7765fc2 in ORBit_c_stub_invoke () from /usr/lib/libORBit-2.so.0
#6  0xb767e65f in GNOME_Evolution_Calendar_CalFactory_getCal (_obj=0xb3600a50, 
    source=0xb3600b30 "<?xml version=\"1.0\"?>\n<source uid=\"1256244172.25695.5@frontdesk\" name=\"\" uri=\"file:///home/tarball/.evolution/calendar/local/system\"/>\n", type=1, listener=0x848e6b0, ev=0xb25ff038)
    at Evolution-DataServer-Calendar-stubs.c:426
#7  0xb7682022 in e_cal_new (source=0x834c420, type=E_CAL_SOURCE_TYPE_EVENT)
    at e-cal.c:1296
#8  0xb7682330 in e_cal_new_from_uri (
    uri=0x8482f68 "file:///home/tarball/.evolution/calendar/local/system", 
    type=E_CAL_SOURCE_TYPE_EVENT) at e-cal.c:1449
#9  0xb76824dd in e_cal_new_system_calendar () at e-cal.c:1478
#10 0xb768b36d in e_cal_open_default (ecal=0xb25ff10c, 
    type=E_CAL_SOURCE_TYPE_EVENT, func=0, data=0x0, error=0xb25ff108)
    at e-cal.c:5135
#11 0xb79c73bb in evo2_ecal_open_cal (path=0x84796e0 "default", 
    source_type=E_CAL_SOURCE_TYPE_EVENT, error=0xb25ff144)
    at /home/cdfrey/software/opensync/git/plugins/evolution2/src/evolution2_ecal.c:67
#12 0xb79c7509 in evo2_ecal_connect (sink=0x83f3648, info=0x83fd338, 
    ctx=0x8482d30, userdata=0x83b6890)
    at /home/cdfrey/software/opensync/git/plugins/evolution2/src/evolution2_ecal.c:91
#13 0xb806ca1f in osync_objtype_sink_connect (sink=0x83f3648, info=0x83fd338, 
    ctx=0x8482d30)
    at /home/cdfrey/software/opensync/git/opensync/opensync/plugin/opensync_objtype_sink.c:327
#14 0xb80235cb in _osync_client_handle_connect (client=0x8354148, 
    message=0x84796b8, error=0xb25ff224)
    at /home/cdfrey/software/opensync/git/opensync/opensync/client/opensync_client.c:1050
#15 0xb80248cf in _osync_client_message_handler (message=0x84796b8, 
    user_data=0x8354148)
    at /home/cdfrey/software/opensync/git/opensync/opensync/client/opensync_client.c:1514
#16 0xb8057c3d in _incoming_dispatch (source=0x8354960, callback=0, 
    user_data=0x8353fc8)
    at /home/cdfrey/software/opensync/git/opensync/opensync/ipc/opensync_queue.c:391
#17 0xb7f701d8 in IA__g_main_context_dispatch (context=0x8354db8)
    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gmain.c:2012
#18 0xb7f73873 in g_main_context_iterate (context=0x8354db8, block=1, 
    dispatch=1, self=0x83580c0)
    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gmain.c:2645
#19 0xb7f73d92 in IA__g_main_loop_run (loop=0x8357bf0)
    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gmain.c:2853
#20 0xb7f9a16f in g_thread_create_proxy (data=0x83580c0)
---Type <return> to continue, or q <return> to quit---
    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gthread.c:635
#21 0xb7bb5f3b in start_thread () from /lib/libpthread.so.0
#22 0xb7ec2bee in clone () from /lib/libc.so.6


(gdb) thread 32
[Switching to thread 32 (Thread 0xb1dffb90 (LWP 25740))]#0  0xb7eb950d in poll
    () from /lib/libc.so.6
(gdb) bt
#0  0xb7eb950d in poll () from /lib/libc.so.6
#1  0xb7f73702 in g_main_context_iterate (context=0x82041b8, block=1, 
    dispatch=1, self=0x835a100)
    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gmain.c:2954
#2  0xb7f73d92 in IA__g_main_loop_run (loop=0x8358108)
    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gmain.c:2853
#3  0xb7f9a16f in g_thread_create_proxy (data=0x835a100)
    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gthread.c:635
#4  0xb7bb5f3b in start_thread () from /lib/libpthread.so.0
#5  0xb7ec2bee in clone () from /lib/libc.so.6


(gdb) thread 33
[Switching to thread 33 (Thread 0xb15ffb90 (LWP 25741))]#0  0xb7eb950d in poll
    () from /lib/libc.so.6
(gdb) bt
#0  0xb7eb950d in poll () from /lib/libc.so.6
#1  0xb7f73702 in g_main_context_iterate (context=0x8204098, block=1, 
    dispatch=1, self=0x835b498)
    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gmain.c:2954
#2  0xb7f73d92 in IA__g_main_loop_run (loop=0x835a048)
    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gmain.c:2853
#3  0xb7f9a16f in g_thread_create_proxy (data=0x835b498)
    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gthread.c:635
#4  0xb7bb5f3b in start_thread () from /lib/libpthread.so.0
#5  0xb7ec2bee in clone () from /lib/libc.so.6


(gdb) thread 34
[Switching to thread 34 (Thread 0xb0dffb90 (LWP 25744))]#0  0x00000000 in ?? ()
(gdb) bt
#0  0x00000000 in ?? ()
#1  0xb7751c3d in giop_thread_queue_process () from /usr/lib/libORBit-2.so.0
#2  0xb7752578 in ?? () from /usr/lib/libORBit-2.so.0
#3  0xb3600808 in ?? ()
#4  0xb3600808 in ?? ()
#5  0xb0dff358 in ?? ()
#6  0xb7feb620 in ?? () from /usr/lib/libglib-2.0.so.0
#7  0xb7feb620 in ?? () from /usr/lib/libglib-2.0.so.0
#8  0xb7feb620 in ?? () from /usr/lib/libglib-2.0.so.0
#9  0xb775253b in ?? () from /usr/lib/libORBit-2.so.0
#10 0xb7feb240 in ?? () from /usr/lib/libglib-2.0.so.0
#11 0x081aaea8 in ?? ()
#12 0xb3600808 in ?? ()
#13 0xb0dff3a8 in ?? ()
#14 0xb7f9b806 in g_thread_pool_thread_proxy (data=0xb3600808)
    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gthreadpool.c:265
Backtrace stopped: frame did not save the PC

Re: [Opensync-devel] demerge_xmlformat does not demerge second level

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

On Wednesday 21 October 2009 06:57:55 pm Henrik /KaarPoSoft wrote:
[...]
> However, on the second level, if we have a <LastName> inside a <Name> in
> the xmlformat, but not in the capabilities, the field is *not* deleted,
> instead the value of the field is set to blank.
> 
> This breaks the logic in xmlformat_compare, which will "Run out of list2
> elements".
[...]
> (1) Does anyone know, WHY the second level of demerge_xmlformat was
> implemented like this? I.e. something that would break if we remove the
> field instead of blanking it?

Hmmm... no idea. I could imagine thats indeed a bug ...

> 
> (2) The top-level loop in demerge_xmlformat efficiently runs through the
> xml fileds with functions like osync_xmlfield_get_next. But the second
> level inefficiently uses indexes into the lists with functions like
> osync_xmlfield_get_nth_key_name. Is there any particular reason for this?
[...]

I could imagine this was very ugly porting when dropping the 2-level limit of 
the xmlformat API to a n-level design.

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] [RFC] Break API: change long to long long?

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

On Thursday 22 October 2009 10:49:54 am Henrik /KaarPoSoft wrote:
> In my opinion the best solution would to break API and change long long 
> to long.
> 

Are there any vetos?
Could someone prepare a patch?


-- 
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] capabilities with attributes

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

On Thursday 22 October 2009 10:47:20 am Henrik /KaarPoSoft wrote:
> So, if I understand correctly, what I need to do to get this to work is 
> two things:
> 1) Patch merger and demerger code in xmlformat plugin
> 2) Add this to my capabilities:
> <Cap>
>  <Name>Telephone</Name>
>  <Parameter>
>   <Name>Location</Name>
>   <ValEnum>Work</ValEnum>
>  </Parameter>
> </Cap>
> 
> It that correct?
> 

Yes, your assumption is correct.
Let me know if you have further question implementing 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