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

Re: [Opensync-devel] [RFC][PATCH][API change] long long patch

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

On Thursday 01 July 2010 04:07:12 pm Chris Frey wrote:
> If nobody objects, I'll commit this to the tree, along with small
> compile fixes to osynctool.  I've attached both patches.
> 

Please go ahead and apply those patches.

Could you add a small porting instruction (maybe based on your osynctool 
porting experience) to the commit message ... to make life easier for those 
who need to adapt to this API change?

Best Regards,
Daniel

-- 
Daniel Gollub                        Geschaeftsfuehrer: Ralph Dehner
Linux Consultant & 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] what is the difference between....?

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

On Friday 09 July 2010 02:14:17 pm Chris Frey wrote:
> What is the difference between these two blocks of code?
> 
> 
>         OSyncFormatEnv *formatenv1 =
>  osync_plugin_info_get_format_env(info); format =
>  osync_format_env_find_objformat(formatenv1,
>                                                 "xmlformat-event-doc");
>         if( !format ) {
>                 osync_trace(TRACE_ERROR, "%s",
>                         "Failed to find objformat xmlformat-event-doc!");
>                 goto error;
>         }


This one is using the OSyncFormatEnv which has access to all format plugins 
which are available to the OpenSync installation. So it has access to all 
available OSyncObjFormats as well ...

Basically this code seems to check if the xmlformat plugin is installed and 
the xmlformat-event-doc objformat ist available.

> 
> 
> And...
> 
>         OSyncPluginConfig *config = osync_plugin_info_get_config(info);
>         OSyncPluginResource *resource =
>  osync_plugin_config_find_active_resource(config, "event");
> 
>         OSyncList *objformatsinks =
>  osync_plugin_resource_get_objformat_sinks(resource);
> 
>         osync_bool has_format = false;
> 
>         OSyncList *r;
>         for( r = objformatsinks; r ;r = r->next ) {
>                 OSyncObjFormatSink *objformatsink = (OSyncObjFormatSink *)
>  r->data;
> 
>                 if( !strcmp("xmlformat-event-doc",
>  osync_objformat_sink_get_objformat(objformatsink))) { has_format = true;
>                         break;
>                 }
>         }
> 
>         if( !has_format ) {
>                 osync_trace(TRACE_ERROR, "%s",
>                         "Failed to find objformat xmlformat-event-doc!");
>                 goto error;
>         }

This one uses the Plugin configuration (OSyncPluginConfig) which contains a 
resource configuraiton. It checks if there is a "event" resource configured 
which uses the xmlformat-event-doc in the objformat-sink in this plugin/member 
configuration.

So the basic difference is:

 block #1: checks if xmlformat-event-doc is available in this particular 
           installation of OpenSync

 block #2: checks if a plugin/member got configured to provide a <Resource> 
           using xmlformat-event-doc


Hope that helps!

Best Regards,
Daniel

-- 
Daniel Gollub                        Geschaeftsfuehrer: Ralph Dehner
Linux Consultant & 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] what is the difference between....?

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

Hi,

What is the difference between these two blocks of code?


	OSyncFormatEnv *formatenv1 = osync_plugin_info_get_format_env(info);
	format = osync_format_env_find_objformat(formatenv1,
						"xmlformat-event-doc");
	if( !format ) {
		osync_trace(TRACE_ERROR, "%s",
			"Failed to find objformat xmlformat-event-doc!");
		goto error;
	}


And...

	OSyncPluginConfig *config = osync_plugin_info_get_config(info);
	OSyncPluginResource *resource = osync_plugin_config_find_active_resource(config, "event");

	OSyncList *objformatsinks = osync_plugin_resource_get_objformat_sinks(resource);

	osync_bool has_format = false;

	OSyncList *r;
	for( r = objformatsinks; r ;r = r->next ) {
		OSyncObjFormatSink *objformatsink = (OSyncObjFormatSink *) r->data;

		if( !strcmp("xmlformat-event-doc", osync_objformat_sink_get_objformat(objformatsink))) {
			has_format = true;
			break;
		}
	}

	if( !has_format ) {
		osync_trace(TRACE_ERROR, "%s",
			"Failed to find objformat xmlformat-event-doc!");
		goto error;
	}


I'm confused. :-)

Thanks,
- Chris

Re: [Opensync-devel] google-calendar plugin maintainer?

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

On Tue, Jul 06, 2010 at 10:17:43PM -0400, Adenilson Cavalcanti wrote:
> > I'm either doing it wrong, or it needs some updating. ?I'm guessing it
> > needs some updating. :-) ?I'll be tinkering with it if nobody stops me.
> >
> 
> If you can help, that would be highly appreciated.
> 
> I wonder if there was any public API libgcal breaking when I did the
> last release (it might require to do the fix in both the libgcal as
> also the opensync plugins).

Hi Adenilson,

Thanks for the reply.  I'm going through the process of getting
the google-calendar plugin to compile again, and yes, there are some
API changes on the opensync side that need to be done.  I vaguely
remember these changes from my experience with the evolution2 and Barry
plugins, so I'm probably in a good spot to update g-c as well.

I'm less familiar with the libgcal side of things, so if I run into
trouble on that side, I'll let you know. :-)

The bulk of changes seems to be opensync-related so far, though.

Thanks,
- Chris

[Opensync-devel] google-calendar plugin maintainer?

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

Hi,

Is the google-calendar plugin actively maintained?  I don't want to step
on toes, and in trying to compile it on a Debian stable system, using
a self-compiled libgcal 0.9.5, I'm getting a number of errors and warnings
for simple things like headers.

I'm either doing it wrong, or it needs some updating.  I'm guessing it
needs some updating. :-)  I'll be tinkering with it if nobody stops me.

Thanks,
- Chris

[Opensync-devel] [patch] filter based on DTSTART

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

On Mon, Jun 28, 2010 at 05:09:02PM -0400, Chris Frey wrote:
> Hi,
> 
> I'm experimenting with syncing using the evo2 plugin and the devel opensync,
> and I get the following error:
> 
> Main sink of member 2 of type evo2-sync had an error: XMLFormat validation failed.
> EXIT_ERROR: _osync_engine_receive_change: XMLFormat validation failed.
> element LastModified: Schemas validity error : Element 'LastModified': This element is not expected. Expected is one of ( DateEnd, DateStarted ).
> ERROR: XMLFormat validation failed.
> EXIT_ERROR: osync_converter_invoke: XMLFormat validation failed.
> EXIT_ERROR: osync_format_env_convert: XMLFormat validation failed.


In my testing, I've found that if I delete things in Evolution, not all
the records in the corresponding calendar.ics files are removed, but instead
get truncated to some short ICal format without a DTSTART.

If I want to "reset" the sync, by deleting the opensync group and starting
the configuration over, deleting everything in Evolution, in order to
do a sync from the Blackberry to Evolution, the evo2-sync plugin picks
these items up during its slow sync mode.  And the XML validation
balks.

It is my understanding that all VEVENT objects must have a DTSTART in them.
Is this correct?  If so, then the following patch to the evo2-sync plugin
should fix this issue.

Thanks,
- Chris


--- a/src/evolution2_ecal.c
+++ b/src/evolution2_ecal.c
@@ -250,7 +250,7 @@ static void evo2_ecal_get_changes(OSyncObjTypeSink *sink, OSyncPluginInfo *info,
                 }
         } else {
                 osync_trace(TRACE_INTERNAL, "slow_sync for %s", evo_cal->objtype);
-	        if (!e_cal_get_object_list_as_comp (evo_cal->calendar, "(contains? \"any\" \"\")", &changes, &gerror)) {
+	        if (!e_cal_get_object_list_as_comp (evo_cal->calendar, "(has-start?)", &changes, &gerror)) {
                         osync_error_set(&error, OSYNC_ERROR_GENERIC, "Failed to get %s changes: %s",  evo_cal->objtype, gerror ? gerror->message : "None");
                         goto error;
         	}

Re: [Opensync-devel] evo2 schema error

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

On Wed, 2010-06-30 at 17:28 -0400, Chris Frey wrote:
> Do tools exist to probe the evolution database from the command line?
> i.e. to see the data that the plugin sees?

Latest SyncEvolution command line from master branch has
"--print-items/export/import". No binaries at this point, you would have
to compile from source.

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

Re: [Opensync-devel] [RFC][PATCH][API change] long long patch

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

Back in November 2009 I posted this patch to remove unneeded long long usage
in opensync, since it was unneeded for opensync's behaviour, and
conflicted with C++.  At the same time I converted the IDs to typedefs,
to make the code cleaner and more flexile.

I posted it for comment, and got no comments, which is understandable
since it is so huge.

I also got distracted with non-sync projects, and didn't have time to
follow up with it.

But it has not died! :-)  This patch is adjusted to fit the latest
SVN tree.  I've been using it in nearly all my sync work over the months
since November, and haven't had any trouble that has been caused
by the patch, to my knowledge.

If nobody objects, I'll commit this to the tree, along with small
compile fixes to osynctool.  I've attached both patches.

Comments welcome.

- Chris

[Opensync-devel] vformat COUNT= patch to remove invalid 0

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

Hi,

When a VEVENT that has a recurring rule with no UNTIL or COUNT fields
is converted from ICAL to xmlformat and back, it suddenly gains an
extra COUNT=0 setting that was not there before.

Comparing against the schema for calendars in the xmlformat plugin
in the schemas/xmlformat-calendar.xsd file:

  <!-- Basic vCalendar Recurence Rule -->
  <xsd:complexType name="RecurrenceRule">
    <xsd:sequence>
      <xsd:element minOccurs="1" maxOccurs="1" name="Frequency" type="BasicRecur
renceFreq"/>
      <xsd:element minOccurs="0" maxOccurs="1" name="Until" type="xsd:string"/>
      <xsd:element minOccurs="0" maxOccurs="1" name="Count" type="PositiveInteger"/>


This PositiveInteger rule excludes 0.

According to my understanding of the RFC 2445, to have a "forever"
recurring rule, COUNT=0 is never used... the COUNT is just dropped.

I've applied the following patch to the vformat plugin.

- Chris



--- a/src/xmlformat-recurrence.c
+++ b/src/xmlformat-recurrence.c
@@ -494,10 +494,6 @@ OSyncXMLField *convert_ical_rrule_to_xml(OSyncXMLFormat *xmlformat, VFormatAttri
 	if (rrules[3].value == NULL)
 		rrules[3].value = "1";
 
-	// set count to 0, if neither count nor until were set before
-	if (rrules[1].value == NULL && rrules[2].value == NULL)
-		rrules[2].value = "0";
-
 	int i;
 	for (i = 0; i <= 13; i++) {
 		if (rrules[i].value != NULL)

Re: [Opensync-devel] evo2 schema error

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

Hi,

Do tools exist to probe the evolution database from the command line?
i.e. to see the data that the plugin sees?

It is odd that the plugin is finding events without start dates or
descriptions.

Thanks,
- Chris

Re: [Opensync-devel] evo2 schema error

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

On Mon, Jun 28, 2010 at 05:09:02PM -0400, Chris Frey wrote:
> Hi,
> 
> I'm experimenting with syncing using the evo2 plugin and the devel opensync,
> and I get the following error:
> 
> Main sink of member 2 of type evo2-sync had an error: XMLFormat validation failed.
> EXIT_ERROR: _osync_engine_receive_change: XMLFormat validation failed.
> element LastModified: Schemas validity error : Element 'LastModified': This element is not expected. Expected is one of ( DateEnd, DateStarted ).
> ERROR: XMLFormat validation failed.
> EXIT_ERROR: osync_converter_invoke: XMLFormat validation failed.
> EXIT_ERROR: osync_format_env_convert: XMLFormat validation failed.

Looks like invalid data in the Evolution database can cause this error,
since no DateStarted ends up in the converted XML.

Not sure yet if this is a bug in the evolution plugin or not, but
blowing away the ~/.evolution directory and starting a fresh sync gets
rid of this error.

- Chris

[Opensync-devel] evo2 schema error

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

Hi,

I'm experimenting with syncing using the evo2 plugin and the devel opensync,
and I get the following error:

Main sink of member 2 of type evo2-sync had an error: XMLFormat validation failed.
EXIT_ERROR: _osync_engine_receive_change: XMLFormat validation failed.
element LastModified: Schemas validity error : Element 'LastModified': This element is not expected. Expected is one of ( DateEnd, DateStarted ).
ERROR: XMLFormat validation failed.
EXIT_ERROR: osync_converter_invoke: XMLFormat validation failed.
EXIT_ERROR: osync_format_env_convert: XMLFormat validation failed.

LastModified doesn't appear to be in the evolution plugin... any tips
on where this might be coming from?

Thanks,
- Chris

Re: [Opensync-devel] leak in osync_member_get_config_or_default?

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

On Fri, Jun 25, 2010 at 05:29:24PM -0400, Chris Frey wrote:
> On Fri, Jun 25, 2010 at 03:21:06PM -0400, Chris Frey wrote:
> > So far, it seems like:
> > 
> > 	- any _new() function requires an _unref()
> > 	- any _set() function will make a copy, so the caller still owns
> > 		the original data
> > 	- any error requires an _unref() of the error object
> > 
> > After that, any other _get()'able data does not need to be freed, such
> > as getting names and strings and even config objects.
> 
> Oops, I found an exception to this.
> 
> osync_plugin_config_get_advancedoptions() returns an osync_list_copy().
> 
> osync_plugin_config_get_resources() returns the direct list pointer.


What do folks think of the idea of renaming each get-style API that
returns a copy to include the word "copy"?

For example:

	osync_plugin_config_get_advancedoptions_copy()

	osync_plugin_config_get_resources()

- Chris

Re: [Opensync-devel] leak in osync_member_get_config_or_default?

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

On Fri, Jun 25, 2010 at 03:21:06PM -0400, Chris Frey wrote:
> So far, it seems like:
> 
> 	- any _new() function requires an _unref()
> 	- any _set() function will make a copy, so the caller still owns
> 		the original data
> 	- any error requires an _unref() of the error object
> 
> After that, any other _get()'able data does not need to be freed, such
> as getting names and strings and even config objects.

Oops, I found an exception to this.

osync_plugin_config_get_advancedoptions() returns an osync_list_copy().

osync_plugin_config_get_resources() returns the direct list pointer.

- Chris

Re: [Opensync-devel] leak in osync_member_get_config_or_default?

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

On Fri, Jun 25, 2010 at 08:24:49PM +1200, Daniel Gollub wrote:
> So if OSyncMember get freed the OSyncPluginConfig gets also freed if no other 
> function wants it shares on that object by increasing the ref-counts of this 
> pointer.
> 
> Does this make more sense now? :)

Yes, thanks. :-)

My next question, which Graham has alluded to, is how do I tell which
functions require an _unref() in the calling code, and which functions don't?

So far, it seems like:

	- any _new() function requires an _unref()
	- any _set() function will make a copy, so the caller still owns
		the original data
	- any error requires an _unref() of the error object

After that, any other _get()'able data does not need to be freed, such
as getting names and strings and even config objects.

I don't think I've seen an explicit rule like this, but it makes sense
from the code I've seen.  The main problem is that I usually have to read
the library code before I'm sure. :-)


> Thanks for finding this ...

You're welcome!

- Chris

Re: [Opensync-devel] leak in osync_member_get_config_or_default?

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

On Friday 25 June 2010 09:24:49 Daniel Gollub wrote:
> The idea how this works is like this:

Hmm.  This explanation works but it doesn't seem quite the right approach to 
me.  I would have thought that any time a function provides a pointer to an 
object to another piece of code, it should have incremented the ref count.  
When the piece of code receiving the pointer no longer needs it it should 
decrement the reference count.

> All osync_XXX_new() calls create "objects" with a refrence count of 1.
> So on the first osync_XXX_unref() call the count decrease to 0 and the
> "object" get freed.

This is consistent with my approach: osync_XXX_new has created an object and 
returned a pointer: so it has set the ref-count to 1.  The caller must unref 
the object when it no longer needs it.

> Ref get increased as soon some other "object" or code starts using this
> "object" as well.

I would have said, ref gets increased as soon as some other code gets a 
pointer to the object (whether it uses it or not).

> In this case the reference get increased since the OSyncMember is going to
> use OSyncPluginConfig*. Since it's no longer used within the
> osync_member_get_config_or_default() function which allocated
> OSyncPluginConfig* we have to decrease the reference once
> osync_member_set_config() get called:

That might be true.   But I would have thought that because the config is 
going to be returned to the caller, it will have increment the ref again, 
just before returning the pointer to the caller.  Once the caller has 
finished doing whatever it wants with the config it unref's it and throws 
away the pointer.  Now the config will be deleted as soon as the member is 
deleted.

In the same way, in the case where it is returning an existing member->config, 
osync_member_get_config_or_default should increase the reference just before 
returning the pointer to the caller.

To understand why I think this way, consider if the caller of 
osync_member_get_config_or_default wants to look at the config but, for some 
reason, decides it doesn't need the member itself any more.  It could unref 
the member but still expect the config pointer to be valid.  

I agree that this particular case is unlikely but it feels like there is a 
general principle: any function that returns a pointer to an object should 
have incremented the ref count on the object; the caller must unref the 
object when it is about to discard the pointer.  After all, it is 
a "reference" count -- a count of the number of pointers to the object which 
exist.

Graham

Re: [Opensync-devel] leak in osync_member_get_config_or_default?

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

On Friday 25 June 2010 08:05:36 pm Chris Frey wrote:
> It doesn't make sense to me yet.... unless the config gets unref'd twice
> later on?

> 
> I'm confused with the _new() and the _set_config()... the
> _new() sets the ref to 1, and the _set_config() bumps it, so it seems
> that the returned config would have a ref of 2, even though it had just
> been created, and only the member holds a ref.


Ah, you're right - i was wrong.

The idea how this works is like this:

All osync_XXX_new() calls create "objects" with a refrence count of 1.
So on the first osync_XXX_unref() call the count decrease to 0 and the 
"object" get freed.

Ref get increased as soon some other "object" or code starts using this 
"object" as well.

In this case the reference get increased since the OSyncMember is going to use 
OSyncPluginConfig*. Since it's no longer used within the 
osync_member_get_config_or_default() function which allocated 
OSyncPluginConfig* we have to decrease the reference once 
osync_member_set_config() get called:


--- opensync/group/opensync_member.c    (revision 6047)
+++ opensync/group/opensync_member.c    (working copy)
@@ -294,6 +294,7 @@
                goto error_free_config;
 
        osync_member_set_config(member, config);
+       osync_plugin_config_unref(config);
 
        osync_free(filename);
 


So if OSyncMember get freed the OSyncPluginConfig gets also freed if no other 
function wants it shares on that object by increasing the ref-counts of this 
pointer.

Does this make more sense now? :)

Thanks for finding this ...


Best Regards,
Daniel

-- 
Daniel Gollub                        Geschaeftsfuehrer: Ralph Dehner
Linux Consultant & 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] leak in osync_member_get_config_or_default?

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

Hi Chris,

On Friday 25 June 2010 02:43:36 pm Chris Frey wrote:
> On success it returns the member->config member directly.
> 
> On error, it loads the default from the default plugin config, calling
> osync_plugin_config_new(), then osync_member_set_config() which seems
> to bump the ref, then returns.

Right.

> 
> So a caller to osync_member_get_config_or_default() doesn't know whether
> to unref the result or not...


The caller doesn't have to unref - since OSyncPluginConfig* gets (in this 
function) or is already assigned to a OSyncMember struct. Once later one get 
freed the OSyncPluginConfig get's also unrefed.

Does this make sense?


Best Regards,
Daniel

-- 
Daniel Gollub                        Geschaeftsfuehrer: Ralph Dehner
Linux Consultant & 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] leak in osync_member_get_config_or_default?

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

On Fri, Jun 25, 2010 at 07:49:57PM +1200, Daniel Gollub wrote:
> The caller doesn't have to unref - since OSyncPluginConfig* gets (in this 
> function) or is already assigned to a OSyncMember struct. Once later one get 
> freed the OSyncPluginConfig get's also unrefed.
> 
> Does this make sense?

Hi Daniel,  Thanks for the reply!

It doesn't make sense to me yet.... unless the config gets unref'd twice
later on?

I'm confused with the _new() and the _set_config()... the
_new() sets the ref to 1, and the _set_config() bumps it, so it seems
that the returned config would have a ref of 2, even though it had just
been created, and only the member holds a ref.

I haven't run this through a debugger yet... this is just from reading
the code, since I'm experimenting with the config API.

Thanks,
- Chris

[Opensync-devel] leak in osync_member_get_config_or_default?

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

Hi,

Following all those refs and unrefs is tough for my poor brain, but
I think I found a leak.

In the file group/opensync_member.c, function:

OSyncPluginConfig *osync_member_get_config_or_default(OSyncMember *member, OSyncError **error)

On success it returns the member->config member directly.

On error, it loads the default from the default plugin config, calling
osync_plugin_config_new(), then osync_member_set_config() which seems
to bump the ref, then returns.

So a caller to osync_member_get_config_or_default() doesn't know whether
to unref the result or not...

- Chris

[Opensync-devel] Failed to build libwbxml on Windows

[Johnson <hao...@gm...>]

Hi,
Has anyone successfully built libwbxml 0.10.8?
I failed to build it with VC++ Express 2008. This is my steps which also can
be found in INSTALL file:
Go to win32, open 'libwbxml.dsw' and build.

The errors are as below:
1>------ Build started: Project: libwbxml2, Configuration: Debug Win32
------
1>Compiling...
1>wbxml_base64.c
1>d:\tech\xml\libwbxml\
libwbxml-0.10.8\src\wbxml.h(38) : fatal error C1083: Cannot open include
file: 'wbxml_config.h': No such file or directory
1>wbxml_buffers.c
1>d:\tech\xml\libwbxml\libwbxml-0.10.8\src\wbxml.h(38) : fatal error C1083:
Cannot open include file: 'wbxml_config.h': No such file or directory
1>wbxml_charset.c
1>d:\tech\xml\libwbxml\libwbxml-0.10.8\src\wbxml.h(38) : fatal error C1083:
Cannot open include file: 'wbxml_config.h': No such file or directory
1>wbxml_conv.c
1>d:\tech\xml\libwbxml\libwbxml-0.10.8\src\wbxml.h(38) : fatal error C1083:
Cannot open include file: 'wbxml_config.h': No such file or directory
1>wbxml_elt.c
1>d:\tech\xml\libwbxml\libwbxml-0.10.8\src\wbxml.h(38) : fatal error C1083:
Cannot open include file: 'wbxml_config.h': No such file or directory
1>wbxml_encoder.c
1>d:\tech\xml\libwbxml\libwbxml-0.10.8\src\wbxml.h(38) : fatal error C1083:
Cannot open include file: 'wbxml_config.h': No such file or directory
1>wbxml_errors.c
1>d:\tech\xml\libwbxml\libwbxml-0.10.8\src\wbxml.h(38) : fatal error C1083:
Cannot open include file: 'wbxml_config.h': No such file or directory
1>wbxml_lists.c
1>d:\tech\xml\libwbxml\libwbxml-0.10.8\src\wbxml.h(38) : fatal error C1083:
Cannot open include file: 'wbxml_config.h': No such file or directory
1>wbxml_log.c
1>d:\tech\xml\libwbxml\libwbxml-0.10.8\src\wbxml.h(38) : fatal error C1083:
Cannot open include file: 'wbxml_config.h': No such file or directory
1>wbxml_mem.c
1>d:\tech\xml\libwbxml\libwbxml-0.10.8\src\wbxml.h(38) : fatal error C1083:
Cannot open include file: 'wbxml_config.h': No such file or directory
1>wbxml_parser.c
1>d:\tech\xml\libwbxml\libwbxml-0.10.8\src\wbxml.h(38) : fatal error C1083:
Cannot open include file: 'wbxml_config.h': No such file or directory
1>wbxml_tables.c
1>d:\tech\xml\libwbxml\libwbxml-0.10.8\src\wbxml.h(38) : fatal error C1083:
Cannot open include file: 'wbxml_config.h': No such file or directory
1>wbxml_tree.c
1>d:\tech\xml\libwbxml\libwbxml-0.10.8\src\wbxml_tree.c(36) : fatal error
C1083: Cannot open include file: 'wbxml_config_internals.h': No such file or
directory
1>wbxml_tree_clb_wbxml.c
1>d:\tech\xml\libwbxml\libwbxml-0.10.8\src\wbxml.h(38) : fatal error C1083:
Cannot open include file: 'wbxml_config.h': No such file or directory
1>wbxml_tree_clb_xml.c
1>d:\tech\xml\libwbxml\libwbxml-0.10.8\src\wbxml_tree_clb_xml.c(36) : fatal
error C1083: Cannot open include file: 'wbxml_config_internals.h': No such
file or directory
1>wbxml_wrap_syncml.c
1>d:\tech\xml\libwbxml\libwbxml-0.10.8\src\wbxml_wrap_syncml.c(25) : fatal
error C1083: Cannot open include file: 'wbxml_config_internals.h': No such
file or directory
1>Generating Code...
1>Build log was saved at
"file://D:\TECH\XML\libwbxml\libwbxml-0.10.8\win32\libwbxml2\Debug\BuildLog.htm"
1>libwbxml2 - 16 error(s), 0 warning(s)
2>------ Build started: Project: test_parser, Configuration: Debug Win32
------
3>------ Build started: Project: wbxml2xml, Configuration: Debug Win32
------
2>Compiling...
3>Compiling...
2>test_parser.c
3>attgetopt.c
2>d:\tech\xml\libwbxml\libwbxml-0.10.8\src\wbxml.h(38) : fatal error C1083:
Cannot open include file: 'wbxml_config.h': No such file or directory
3>wbxml2xml_tool.c
3>d:\tech\xml\libwbxml\libwbxml-0.10.8\tools\wbxml2xml_tool.c(40) : fatal
error C1083: Cannot open include file: 'src/wbxml.h': No such file or
directory
3>Generating Code...
2>Build log was saved at
"file://D:\TECH\XML\libwbxml\libwbxml-0.10.8\win32\test_parser\Debug\BuildLog.htm"
2>test_parser - 1 error(s), 0 warning(s)
3>Build log was saved at
"file://D:\TECH\XML\libwbxml\libwbxml-0.10.8\win32\wbxml2xml\Debug\BuildLog.htm"
3>wbxml2xml - 1 error(s), 0 warning(s)
4>------ Build started: Project: xml2wbxml, Configuration: Debug Win32
------
4>Compiling...
4>attgetopt.c
4>xml2wbxml_tool.c
4>d:\tech\xml\libwbxml\libwbxml-0.10.8\tools\xml2wbxml_tool.c(40) : fatal
error C1083: Cannot open include file: 'src/wbxml.h': No such file or
directory
4>Generating Code...
4>Build log was saved at
"file://D:\TECH\XML\libwbxml\libwbxml-0.10.8\win32\xml2wbxml\Debug\BuildLog.htm"
4>xml2wbxml - 1 error(s), 0 warning(s)
========== Build: 0 succeeded, 4 failed, 0 up-to-date, 0 skipped ==========


-- 
Best and Regards
Johnson

[Opensync-devel] trac spammed

[Fernando T. <ft...@do...>]

Hi people i see that the Trac was spammed and the search option is not working 
(maybe relate to the doxygen plugin)

i have some knowledge on Trac and may help us. 
feel free to contact me.
Saludos!
-- 
Dock Sud BBS
http://bbs.docksud.com.ar
telnet://bbs.docksud.com.ar

[Opensync-devel] [PATCH]irmc-plugin

[Volker S. <vo...@sc...>]

Hello developers,

the irmc plugin got ported to the current API (0.39). Now the irmc
plugin compiles without errors and it is possible for me to syncronize
contacts of my mobile phone (Siemens Benq E71) to the file plugin. If i
try to synchronize my calendar data of my phone to the file plugin i get
the following error:

Error Summary:
ROOT CAUSE: "Couldn't find Object Type Engine for Object Type "event"
while preparing for write phase."

So i ask the question who is responsible to build this Object Type
Engine? Is it Plugin depending or is it missing in libopensync general?
I attached the patch for the irmc plugin.

Greetings

Volker Schreiner

[Opensync-devel] [PATCH]msynctool

[Volker S. <vo...@sc...>]

This patch adapts the msynctool to the new api of opensync and thus
fixes some compile errors of the project. Furthermore the interface of
the msync_plugin was changed to:

void (* MSyncPluginGetConfig)(MSyncPlugin*, OSyncPluginConfig *config );

This was neccessary because the OSyncPluginConfig does not provide a
method to set a new configuration as a char *. Now the
MSyncPluginGetConfig returns not the character representation of the
config file but it updates the OSyncPluginConfig in the plugin dependant
getConfig method.
As a prove of concept a msync plugin for the file-sync plugin was
implemented.
The evo2-sync plugin was added to the plugin list but is not working
correct until now.

Best Regards

Volker Schreiner

Re: [Opensync-devel] [PATCH] Plugin authentication feature issue

[Nicolas <pr...@fr...>]

Le dimanche 18 avril 2010 à 10:50 +0200, Daniel Gollub a écrit :
> Hi Nicolas,
> 
> On Saturday 17 April 2010 01:50:50 pm Nicolas wrote:
> > So you find in attachment a little patch to fix the serializer function.
> > 
> 
> looks good to me.
> Patch applied - r6045
> 
> Thanks for your contribution. Looking forward to more patches ;)

He :)

In my today using, I haven't other bug.

Which bug do you think in particular ? If I can help you to fix some
bugs, I can seek.

Regards,

Nicolas