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

[Opensync-devel] xmlformat plugin and timestamp formats

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

Hi,

Considering that the xmlformat is based on the vformat RFCs, is it
proper to assume that the formats of each field are also limited to
the RFCs?

For example, take a DTSTART timestamp, which can be:

	20100810T100000Z

But *cannot* be:

	2010-08-10T10:00:00Z

Due to the specification of iCalendar which says:

	"There are no separator characters between the year, month and day
	component text."
	   - section 4.3.4
	     http://tools.ietf.org/html/rfc2445#page-34

Even though this is a valid ISO 8601 timestamp:

	http://en.wikipedia.org/wiki/ISO_8601

Has any thought been given to the actual format of the timestamp for the
xmlformat versions of fields like DateStart?  The reason I ask, is because
Google calendar is fairly strict about using ISO 8601 with dashes and colons,
while vformat is pretty strict about using its own variant of ISO 8601
without them.  I just want to know where I should be converting things.
I think the best place is either in the vformat plugin or xmlformat
plugin, or both.

Thanks,
- Chris

Re: [Opensync-devel] Fwd: Google plugin for opensync

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

On Fri, Aug 13, 2010 at 10:32:56AM +0200, Quentin Denis wrote:
> I think it is high time to finally
> release a stable 0.40 version, including up-to-date plugins (the engine
> without plugins makes the project useless).

Hi Quentin,

I quite agree with the above, and I think the first step in fixing this
situation is to bring all the engine and plugin sources together into
one SVN or git repository, and get rid of the SVN externals stuff, which
makes it harder to interface with other SCM software.

If it is possible for a developer to make a change in the engine, and
run 'make' and automatically compile all plugins and thereby test that
the API has at least been updated for all plugins, I think development
would be smoother.  Sort of like how the linux kernel has all the modules
included, and if you change the kernel, the modules break automatically,
and the compiler helps you update things.


ATTENTION anyone reading this thread: please let me know if this will cause
trouble that I don't foresee.  I plan to update at least the opensync SVN
to get rid of its externals if possible, and put all plugins into it.


> So, my recommendation is to concentrate all the efforts on a new stable
> release with all plugins working before these two projects dethrone you. The
> next urgent thing would be then to create an Akonadi plugin [1] and the
> opensync suite is back on the desktop!
> Try to create a buzz around the new and finally stable release. Publish beta
> versions and release candidates. Announce news on the website; show that you
> are still actively developing it. ... And I will update the wiki, I promise!

I see you've already updated the wiki... nice!  Thanks!


> Concerning the google plugin, Adenilson told me about the current features
> of libgcal:
> 
> "Later in 2008, I asked his permission to continue this work, and started by
> first writing a C library for google data protocol (libgcal) implementing
> both calendar and contacts. And at the same year I re-wrote the opensync
> gcalendar plugin and wrote  a new contacts plugin.
> 
> In 2009, I started akonadi resources using libgcal. You can read more about
> both in here:
> http://savago.wordpress.com/2010/06/11/libgcal-0-9-4-released/
> http://savago.wordpress.com/2010/06/20/libgcal-0-9-5-plus-a-video/
> "

You also mentioned "tasks" in your earlier email... I can see libgcal API
for contacts and calendar, but not sure about tasks.

I'm close to committing some patches to the google-calendar plugin that
gets calendar working nicely again.  Just have to hammer out some timestamp
conversion issues.

- Chris

Re: [Opensync-devel] Fwd: Google plugin for opensync

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

Hi Chris,

thank you very much for your long response and the clearing up of the
situation. I am happy to know that there is still a motivated and very
active developer in the opensync team. I think it is high time to finally
release a stable 0.40 version, including up-to-date plugins (the engine
without plugins makes the project useless). I have recently been in contact
with former opensync contributors or potential contributors, there all told
me that they stopped working on opensync because of its constant API changes
and lack of progress and stability.

I my opinion, it is urgent to bring opensync back on track. Many users and
developers are disappointed of the stalled progress and moved towards other
solutions. Some innovative projects will some make opensync a dead and
outdated application, two projects in particular are about to bring the
ultimate solution for KDE users:
- http://saidinesh5.wordpress.com/
<http://saidinesh5.wordpress.com/>- https://akunambol.forge.funambol.org/
So, my recommendation is to concentrate all the efforts on a new stable
release with all plugins working before these two projects dethrone you. The
next urgent thing would be then to create an Akonadi plugin [1] and the
opensync suite is back on the desktop!
Try to create a buzz around the new and finally stable release. Publish beta
versions and release candidates. Announce news on the website; show that you
are still actively developing it. ... And I will update the wiki, I promise!

Concerning the google plugin, Adenilson told me about the current features
of libgcal:

"Later in 2008, I asked his permission to continue this work, and started by
first writing a C library for google data protocol (libgcal) implementing
both calendar and contacts. And at the same year I re-wrote the opensync
gcalendar plugin and wrote  a new contacts plugin.

In 2009, I started akonadi resources using libgcal. You can read more about
both in here:
http://savago.wordpress.com/2010/06/11/libgcal-0-9-4-released/
http://savago.wordpress.com/2010/06/20/libgcal-0-9-5-plus-a-video/
"

So, I don't know what is really implemented in the opensync plugin; but
libgcal provides all these features. According to Adenilson, he has already
given up altogether of maintaining the opensync plugins and decided to
maintain the akonadi resources (which can be used with Kontact and
Kaddressbook).

Ok, so far so good, I hope things will evolve the best as opensync deserves.

Best regards and nice work,
Quentin Denis
<http://savago.wordpress.com/2010/06/20/libgcal-0-9-5-plus-a-video/>

[1] Some work has been done on it quite a while ago; but it seems to have
been removed from svn:
http://websvn.kde.org/trunk/playground/pim/
There you will also find discontinued projects like kitchensync
(discontinued because of the constant API changes, too).


On Thu, Aug 12, 2010 at 7:44 PM, Chris Frey <cd...@fo...> wrote:

> Hi Quentin,
>
> Thanks for your message... I'll reply to the list, in case others wish
> to join in.
>
> I guess you could say that I'm the latest in a line of maintainers
> for the google-calendar plugin.  I'm interested in getting opensync
> 0.39 working for personal reasons.  I'd like to see opensync continue,
> and I think 0.4x is so close to being useful that it would be a shame
> to drop it now.
>
> The primary issue is lack of ported plugins, and I'm working on that
> slowly.
>
> I think I might be the only developer committing code at the moment,
> though.
> And slowly at that!  But the 0.39 engine is useable, and arguably better
> than 0.22.  If the plugins were up to date, I think we could release it,
> and get more interest from users and maybe developers.
>
> I haven't followed Akonadi too closely.  Does it have the same range of
> syncing abilities that opensync 0.22 has?
>
> As for adding tasks support to the Google plugin, that would require
> support to be added in libgcal, and I don't think it's there yet?
> If libgcal had that support, I'd be interested in updating the plugin
> to support it.
>
> Adenilson, does libgcal support tasks and I just don't see it?
>
> - Chris
>
>
>
> On Thu, Aug 12, 2010 at 10:28:31AM +0200, Quentin Denis wrote:
> > Hello,
> >
> > I have sent this message to the authors of the google-calendar plugin, it
> > might interest you, too. I would be especially interested in getting
> status
> > update of the Akonadi plugin; this would bring back a lot of KDE users
> and
> > make opensync revive.
> >
> > Best regards,
> > Quentin Denis
> >
> >
> > ---------- Forwarded message ----------
> > From: Quentin Denis <que...@gm...>
> > Date: Thu, Aug 12, 2010 at 10:00 AM
> > Subject: Google plugin for opensync
> > To: ade...@in..., cd...@fo...,
> eha...@ra...
> >
> >
> > Hello guys,
> >
> > thanks to you, opensync has a powerful google calendar plugin. Lately,
> > Google has improved it's features and now offers "Tasks" and improved
> > "Contact". It would be nice to sync both with my Gnokii "Notes" and
> > "Addressbook", so are you interested in extending the existing plugin to
> > include these new features? It would bring a lot of users back to
> opensync
> > since this is a very useful synchronisation element. Opensync is too
> > restricted to Gnome users (evolution, tomboy, ...) and a complete Google
> > plugin would enable other users to escape this lack of plugins (KDE4
> plugin
> > being as dead as it has never been...).
> >
> > By the way, could enlighten me about the actual development status of
> > opensync? Is it still very active or is it moving to a dead end? Are all
> the
> > plugins compatible with the latest opensync api? What about Akonadi
> support?
> >
> > Thanks a lot for your work and looking forward to enjoying a more
> complete
> > Google plugin,
> > kind regards,
> > Quentin Denis
>
> >
> ------------------------------------------------------------------------------
> > This SF.net email is sponsored by
> >
> > Make an app they can't live without
> > Enter the BlackBerry Developer Challenge
> > http://p.sf.net/sfu/RIM-dev2dev
> > _______________________________________________
> > Opensync-devel mailing list
> > Ope...@li...
> > https://lists.sourceforge.net/lists/listinfo/opensync-devel
>
>

Re: [Opensync-devel] Fwd: Google plugin for opensync

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

Hi Quentin,

Thanks for your message... I'll reply to the list, in case others wish
to join in.

I guess you could say that I'm the latest in a line of maintainers
for the google-calendar plugin.  I'm interested in getting opensync
0.39 working for personal reasons.  I'd like to see opensync continue,
and I think 0.4x is so close to being useful that it would be a shame
to drop it now.

The primary issue is lack of ported plugins, and I'm working on that
slowly.

I think I might be the only developer committing code at the moment, though.
And slowly at that!  But the 0.39 engine is useable, and arguably better
than 0.22.  If the plugins were up to date, I think we could release it,
and get more interest from users and maybe developers.

I haven't followed Akonadi too closely.  Does it have the same range of
syncing abilities that opensync 0.22 has?

As for adding tasks support to the Google plugin, that would require
support to be added in libgcal, and I don't think it's there yet?
If libgcal had that support, I'd be interested in updating the plugin
to support it.

Adenilson, does libgcal support tasks and I just don't see it?

- Chris



On Thu, Aug 12, 2010 at 10:28:31AM +0200, Quentin Denis wrote:
> Hello,
> 
> I have sent this message to the authors of the google-calendar plugin, it
> might interest you, too. I would be especially interested in getting status
> update of the Akonadi plugin; this would bring back a lot of KDE users and
> make opensync revive.
> 
> Best regards,
> Quentin Denis
> 
> 
> ---------- Forwarded message ----------
> From: Quentin Denis <que...@gm...>
> Date: Thu, Aug 12, 2010 at 10:00 AM
> Subject: Google plugin for opensync
> To: ade...@in..., cd...@fo..., eha...@ra...
> 
> 
> Hello guys,
> 
> thanks to you, opensync has a powerful google calendar plugin. Lately,
> Google has improved it's features and now offers "Tasks" and improved
> "Contact". It would be nice to sync both with my Gnokii "Notes" and
> "Addressbook", so are you interested in extending the existing plugin to
> include these new features? It would bring a lot of users back to opensync
> since this is a very useful synchronisation element. Opensync is too
> restricted to Gnome users (evolution, tomboy, ...) and a complete Google
> plugin would enable other users to escape this lack of plugins (KDE4 plugin
> being as dead as it has never been...).
> 
> By the way, could enlighten me about the actual development status of
> opensync? Is it still very active or is it moving to a dead end? Are all the
> plugins compatible with the latest opensync api? What about Akonadi support?
> 
> Thanks a lot for your work and looking forward to enjoying a more complete
> Google plugin,
> kind regards,
> Quentin Denis

> ------------------------------------------------------------------------------
> This SF.net email is sponsored by 
> 
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev 
> _______________________________________________
> Opensync-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Opensync-devel] Fwd: Google plugin for opensync

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

Hello,

I have sent this message to the authors of the google-calendar plugin, it
might interest you, too. I would be especially interested in getting status
update of the Akonadi plugin; this would bring back a lot of KDE users and
make opensync revive.

Best regards,
Quentin Denis


---------- Forwarded message ----------
From: Quentin Denis <que...@gm...>
Date: Thu, Aug 12, 2010 at 10:00 AM
Subject: Google plugin for opensync
To: ade...@in..., cd...@fo..., eha...@ra...


Hello guys,

thanks to you, opensync has a powerful google calendar plugin. Lately,
Google has improved it's features and now offers "Tasks" and improved
"Contact". It would be nice to sync both with my Gnokii "Notes" and
"Addressbook", so are you interested in extending the existing plugin to
include these new features? It would bring a lot of users back to opensync
since this is a very useful synchronisation element. Opensync is too
restricted to Gnome users (evolution, tomboy, ...) and a complete Google
plugin would enable other users to escape this lack of plugins (KDE4 plugin
being as dead as it has never been...).

By the way, could enlighten me about the actual development status of
opensync? Is it still very active or is it moving to a dead end? Are all the
plugins compatible with the latest opensync api? What about Akonadi support?

Thanks a lot for your work and looking forward to enjoying a more complete
Google plugin,
kind regards,
Quentin Denis

Re: [Opensync-devel] status moto plugin

[Harald J. <ha...@a-...>]

On Sat, Jul 31, 2010 at 06:26:07PM +0100, Mark Ellis wrote:
> On Thu, 2010-07-29 at 23:18 +0200, Chris Frey wrote:
> > On Wed, Jul 28, 2010 at 08:21:23AM +0200, Harald Jenny wrote:
> > > Hi all,
> > > 
> > > I've tried to get the moto plugin working with opensync 0.39 but did run into
> > > some problems (mainly because I do not speak python). May I ask if there is
> > > anybody working on it or if there is someone who could help me getting it
> > > work again?
> > 
> > The last change date in SVN is August 2008, referencing 0.38.
> > I'm not aware of anyone working on it, and I don't have a motorola phone.
> > 
> > I can't promise much help, but maybe if you posted the error messages you
> > were getting, someone might know where to point you.
> > 
> > - Chris
> 
> I can't say much about the moto plugin, but I've been trying to get the
> python module into shape for use with the synce plugin, I'd be
> interested to hear about your experiences.

Well the first thing I have to fix is the changed config file syntax... my
prototype is currently:

<?xml version="1.0"?>
<config version="1.0">
  <Connection>
    <ActiveConnection>Serial</ActiveConnection>
    <Serial>
      <DeviceNode>/dev/ttyACM0</DeviceNode>
    </Serial>
  </Connection>
</config>

but I'm not sure if this is correct.

> 
> Mark

Harald

> 
> 



> ------------------------------------------------------------------------------
> The Palm PDK Hot Apps Program offers developers who use the
> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
> of $1 Million in cash or HP Products. Visit us here for more details:
> http://p.sf.net/sfu/dev2dev-palm

> _______________________________________________
> Opensync-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensync-devel

Re: [Opensync-devel] status moto plugin

[Harald J. <ha...@a-...>]

On Thu, Jul 29, 2010 at 05:18:14PM -0400, Chris Frey wrote:
> On Wed, Jul 28, 2010 at 08:21:23AM +0200, Harald Jenny wrote:
> > Hi all,
> > 
> > I've tried to get the moto plugin working with opensync 0.39 but did run into
> > some problems (mainly because I do not speak python). May I ask if there is
> > anybody working on it or if there is someone who could help me getting it
> > work again?
> 
> The last change date in SVN is August 2008, referencing 0.38.
> I'm not aware of anyone working on it, and I don't have a motorola phone.

Well I own a V3 (which is the reason why I'm interested in it).

> 
> I can't promise much help, but maybe if you posted the error messages you
> were getting, someone might know where to point you.

The first thing is the changed config file syntax - moto-sync uses device names
for USB and Bluetooth connectivity. Is it still possible to use such names and
if yes how can it be specified?

Current syntax:

<?xml version="1.0"?>
<config>
  <!-- device file name of the phone (/dev/ttyACM0 or /dev/rfcomm0) -->
  <device></device>
</config>

> 
> - Chris

Harald

> 
> 
> ------------------------------------------------------------------------------
> The Palm PDK Hot Apps Program offers developers who use the
> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
> of $1 Million in cash or HP Products. Visit us here for more details:
> http://p.sf.net/sfu/dev2dev-palm
> _______________________________________________
> Opensync-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensync-devel

Re: [Opensync-devel] status moto plugin

[Mark E. <ma...@mp...>]

On Thu, 2010-07-29 at 23:18 +0200, Chris Frey wrote:
> On Wed, Jul 28, 2010 at 08:21:23AM +0200, Harald Jenny wrote:
> > Hi all,
> > 
> > I've tried to get the moto plugin working with opensync 0.39 but did run into
> > some problems (mainly because I do not speak python). May I ask if there is
> > anybody working on it or if there is someone who could help me getting it
> > work again?
> 
> The last change date in SVN is August 2008, referencing 0.38.
> I'm not aware of anyone working on it, and I don't have a motorola phone.
> 
> I can't promise much help, but maybe if you posted the error messages you
> were getting, someone might know where to point you.
> 
> - Chris

I can't say much about the moto plugin, but I've been trying to get the
python module into shape for use with the synce plugin, I'd be
interested to hear about your experiences.

Mark

Re: [Opensync-devel] status moto plugin

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

On Wed, Jul 28, 2010 at 08:21:23AM +0200, Harald Jenny wrote:
> Hi all,
> 
> I've tried to get the moto plugin working with opensync 0.39 but did run into
> some problems (mainly because I do not speak python). May I ask if there is
> anybody working on it or if there is someone who could help me getting it
> work again?

The last change date in SVN is August 2008, referencing 0.38.
I'm not aware of anyone working on it, and I don't have a motorola phone.

I can't promise much help, but maybe if you posted the error messages you
were getting, someone might know where to point you.

- Chris

[Opensync-devel] status moto plugin

[Harald J. <ha...@a-...>]

Hi all,

I've tried to get the moto plugin working with opensync 0.39 but did run into
some problems (mainly because I do not speak python). May I ask if there is
anybody working on it or if there is someone who could help me getting it
work again?

Kind regards
Harald Jenny

[Opensync-devel] plugin paths and configs

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

Hi,

Is there a way to find the defaults directory (where the default config
starter files are stored) automatically inside the plugin?

The google-calendar plugin has an advanced option in its config that
holds the path to where its .xslt files are.  It would be nice to
be able to make this an optional specification, so the plugin could
find the default-installed .xslt files without the user needing
to know the directory hierarchy of libopensync.

I notice that osync_member_get_config_or_default() uses OPENSYNC_CONFIGDIR,
but there's no API call to return this directory name that I can see.

If this isn't possible with the current API, anybody have objections to
adding one?

Thanks,
- Chris

[Opensync-devel] libsyncml and SWIG

[griffin <gr...@ub...>]

hi opensync-devel,

i'd like to add SyncML support to a python-based web server, and
looked around for a python syncml library, but could not find
anything very promising. so have started toying with the idea of
adding a SWIG wrapper to your libsyncml. being completely
unfamiliar with the architecture, i am not sure if this is the
right approach and wanted your guidance here... some questions:

- is there a better way or a library that you are aware of that
   would be better suited?

- since the request will be received by python, can libsyncml be
   used in such a way that it is not actually listening to the
   socket, but is instead invoked with an open data stream?

any help appreciated and i hope that i can contribute useful
code via SWIG so that as many languages as possible can easily
use libsyncml!

thanks in advance,
griffin

Re: [Opensync-devel] Patch for branch-0.2X/plugins/sunbird to sync VTODO items

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

On Sun, Jul 11, 2010 at 12:35:31PM +0200, Oswald wrote:
> Hello,
> 
> I've got a patch that adds synchronization of VTODO items to the sunbird 
> plugin. Where can I put it?

If you have access to the ticket system, you can put it there:

	http://opensync.org/report/12

Otherwise, you can post the patch to the mailing list so folks can look at it
and review it.

- Chris

[Opensync-devel] Patch for branch-0.2X/plugins/sunbird to sync VTODO items

[Oswald <Osw...@Fe...>]

Hello,

I've got a patch that adds synchronization of VTODO items to the sunbird 
plugin. Where can I put it?

Greetings,
Oswald
-- 
http://www.stud.fernuni-hagen.de/q8179670

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

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

Chris Frey wrote:
> On Fri, Jul 09, 2010 at 05:18:02PM +0200, Henrik /KaarPoSoft wrote:
>   
>> Chris Frey wrote:
>>     
>>> Thank you very much.  After I get google-calendar working, I was planning
>>> to look at sunbird.  I used to use that in 0.22, but I don't see that
>>> in 0.3x yet.  Is the "mozilla-sync" plugin where sunbird should go?
>>>
>>>   
>>>       
>> mozilla-sync should already "almost" work with sunbird
>> http://bluezync.kaarposoft.dk/
>>     
>
> Ahh... thanks.  Is that the official home of the mozilla-sync plugin?
>   
As official as it gets ((-;
> I was looking in the opensync svn and the tree looked pretty empty.
>   
It is an external plugin, so all of the code is in blueZync.
The opensync tree just has the config files.
> Looking at http://bluezync.kaarposoft.dk/0.1.6/building.html
> it gives me the following command to grab the plugin:
>
> svn co https://bluezync.svn.sourceforge.net/svnroot/bluezync/trunk/libopensync-plugin-mozilla libopensync-plugin-mozilla
>
> But it looks like it's been moved?  Almost looks like I need to compile
> bluezync to get it.
>
>   
Don't waste time on the old 0.1.6.
You must compile from source:
http://bluezync.kaarposoft.dk/building.html

/Henrik

Re: [Opensync-devel] Plugin porting HOWTO

[Bjoern R. <bjo...@go...>]

Thanks a lot for your work! It should be really helpful for other
developers.

Regards,
Bjoern

Am 09.07.10 22:18, schrieb Chris Frey:
> Hi folks,
>
> Just like Daniel requested, here's my quick and dirty list of steps
> for porting old plugins.  Hope it helps some folks.
>
> - Chris

[Opensync-devel] Plugin porting HOWTO

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

Hi folks,

Just like Daniel requested, here's my quick and dirty list of steps
for porting old plugins.  Hope it helps some folks.

- Chris





A Brief HOWTO on Porting Out of Date OpenSync Plugins to the Latest API
=======================================================================

This article documents some of the steps I took to update the google-calendar
plugin to the latest opensync API.

Disclaimer: I am no opensync expert, and you read this document at your
own risk.  But hopefully it will give you a head start on doing any porting.

1) Compile with warnings
------------------------

Most useful thing to do, right away, is to setup your cmake properly,
for maximum pain.... I mean, turn on all warnings. :-)

This is the script I run to setup my opensync and plugin builds:

------------------------------------------------------------------------------
#!/bin/sh

mkdir build
cd build
cmake -Wdev \
	-DCMAKE_INSTALL_PREFIX=/home/cdfrey/software/opensync/git/rootdir \
	-DCMAKE_C_COMPILER:STRING=/usr/local/bin/ccache_gcc \
	-DCMAKE_CXX_COMPILER:STRING=/usr/local/bin/ccache_g++ \
	-DCMAKE_C_FLAGS:STRING="-Wall -Werror -O0" \
	-DCMAKE_CXX_FLAGS:STRING="-Wall -Werror -O0" \
	-DCMAKE_C_FLAGS_RELWITHDEBINFO:STRING="-g" \
	-DCMAKE_VERBOSE_MAKEFILE:BOOL=TRUE \
	..

echo "You can now run: cd build ; make ; make install"

------------------------------------------------------------------------------


2) OSyncLists need to be freed
------------------------------

The latest API makes a copy of all OSyncLists that it returns.  This means
that you must call osync_list_free() on all such lists yourself.


3) Sink pointers do not need to be stored anymore
-------------------------------------------------

Older plugins would create the sinks for each objtype they would support,
and then store the pointers of those sinks in their environment data,
or would fetch it through the plugin info pointer passed to the callbacks.

Neither is necessary anymore, since the sink pointer is passed in to the
callbacks.  This will require you to update your callback prototypes,
and change any code that used to call osync_plugin_info_get_sink(info),
which is obsolete.


4) New error handling
---------------------

The latest API makes heavy use of OSyncError, and it is the owner's
responsibility to clean this up.

The first example is if you call a function that uses the error pointer.
This is the logic you will need:

	OSyncError *error = NULL;
	if( !osync_some_error_returning_function(info, &error) ) {
		osync_trace(OSYNC_ERROR, "Can't load! %s",
			osync_error_print(&error));
		osync_error_unref(&error);
		return FALSE;
	}

The second example is if you are coding a function that accepts an OSyncError**
pointer itself.  The main function get_sync_info() is like this.  For example:

	osync_bool get_sync_info(OSyncPluginEnv *env, OSyncError **error)
	{
		OSyncPlugin *plugin = osync_plugin_new(error);
		if( !plugin )
			goto error;

		osync_plugin_set_name(plugin, "google-data");
		osync_plugin_set_longname(plugin, "Google calendar/plugin");
		osync_plugin_set_description(plugin,
					"Google calendar and contacts plugin");

		osync_plugin_set_initialize(plugin, gc_initialize);
		osync_plugin_set_finalize(plugin, gc_finalize);
		osync_plugin_set_discover(plugin, gc_discover);

		if( !osync_plugin_env_register_plugin(env, plugin, error) )
			goto error;
		osync_plugin_unref(plugin);

		osync_trace(TRACE_EXIT, "%s", __func__);
		return TRUE;

	error:
		osync_trace(TRACE_EXIT_ERROR, "Unable to register: %s",
				osync_error_print(error));
		return FALSE;
	}

Note that the error is not freed here, since it is passed back to the
caller of get_sync_info(), who has the responsibility to free it.


5) Authentication has its own API
---------------------------------

Instead of looping through resources, you can fetch the username and
password configuration options through the following APIs:

       OSyncPluginAuthentication *optauth = NULL;
       optauth = osync_plugin_config_get_authentication(config);
       if( osync_plugin_authentication_option_is_supported(optauth,
                               OSYNC_PLUGIN_AUTHENTICATION_USERNAME) ) {
               const char *user =
                       osync_plugin_authentication_get_username(optauth);
               if( !user )
                       goto error_freeplg;

and the same for password.


6) Callback registration: from struct to individual functions
-------------------------------------------------------------

The old style of registering your plugin sink callbacks was through
the setup of a struct bundle, like so:

	OSyncObjTypeSinkFunctions functions_gcont;
	memset(&functions_gcont, 0, sizeof(functions_gcont));
	functions_gcont.connect = gc_connect;
	functions_gcont.get_changes = gc_get_changes_contact;
	functions_gcont.commit = gc_commit_change_contact;
	functions_gcont.disconnect = gc_disconnect;
	functions_gcont.sync_done = gc_sync_done;

	sync_objtype_sink_set_functions(sink, functions_gcont, envdata);
	osync_plugin_info_add_objtype(info, sink);


This is now done with individual function calls:

	osync_objtype_sink_set_connect_func(sink, gc_connect_contact);
	osync_objtype_sink_set_disconnect_func(sink, gc_disconnect);
	osync_objtype_sink_set_get_changes_func(sink, gc_get_changes_contact);
	osync_objtype_sink_set_commit_func(sink, gc_commit_change_contact);
	osync_objtype_sink_set_sync_done_func(sink, gc_sync_done);

	osync_objtype_sink_set_userdata(sink, plgdata);

Adding the objtype to the plugin info via osync_plugin_info_add_objtype()
is not required anymore.

Note that you probably want to make all this registration conditional on
whether the sink is enabled or not in your configuration, like this:

	OSyncObjTypeSink *sink = osync_plugin_info_find_objtype(info,"contact");
	if( sink && osync_objtype_sink_is_enabled(sink) ) {
		// do registration
	}



7) New discover() step
----------------------

There is a new step in the latest API called discover, which gives the
plugin a chance to report what it supports.  I don't fully understand
the potential of this stage, but I do know that it is mixture of
plugin configuration and plugin abilities.

The easiest way to code this is to enable all sinks that your plugin
supports.  These sinks are the ones you just registered above.

       OSyncList *sinks = osync_plugin_info_get_objtype_sinks(info);
       OSyncList *s = sinks;
       for( ; s; s = s->next ) {
               OSyncObjTypeSink *sink = (OSyncObjTypeSink*) s->data;
               osync_objtype_sink_set_available(sink, TRUE);
       }


8) Anchor API has been renamed to state_db
------------------------------------------

The old anchor API has been renamed to state_db, and mostly this is a
simple straight renaming of:

	osync_objtype_sink_get_anchor()
	osync_anchor_retrieve()
	osync_anchor_update()
	osync_objtype_sink_enable_anchor()

to (respectively):

	osync_objtype_sink_get_state_db()
	osync_sink_state_get()
	osync_sink_state_set()
	osync_objtype_sink_enable_state_db()

The only difference is that the get() and set() functions now take a
key name.  This can be anything, but it must be consistent.  Think of it
like a Berkeley DB get/set, and you need to use the same key you use
for saving when you retrieve again.

I just use hard coded strings here, like "contact_timestamp", etc.


9) Slow sync is now an argument, instead of a function call
-----------------------------------------------------------

Instead of:

	if (osync_objtype_sink_get_slowsync(plgdata->gcal_sink)) {

use the slow_sync bool variable passed into the new callback prototype:

	if (slow_sync) {


10) List looping is more standard
---------------------------------

In the old API, you would get functions that would return the total
number of items in a list, and a means to get the nth item.

In the new API, it is more encouraged to access these things via
OSyncLists, which are standard ways of looping through lists:

	OSyncList *s = NULL, *list = osync_plugin_info_get_objtype_sinks(info);
	for( s = list; s; s = s->next ) {
		OSyncObjTypeSink *sink = (OSyncObjTypeSink*) s->data;
		// do work...
	}

This replaces functions such as osync_plugin_info_num_objtypes() and
osync_plugin_info_nth_objtype() which are obsolete.


11) Some headers may have changed
---------------------------------

Most of these errors you will find during the compilation, but
headers such as opensync-context.h are obsolete.  Search through
the opensync include directory for the latest headers.



If all else fails, post a plea for help to the opensync-devel mailing list.
That's what I do. :-)

- Chris

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

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

On Fri, Jul 09, 2010 at 05:18:02PM +0200, Henrik /KaarPoSoft wrote:
> Chris Frey wrote:
> >
> >
> > Thank you very much.  After I get google-calendar working, I was planning
> > to look at sunbird.  I used to use that in 0.22, but I don't see that
> > in 0.3x yet.  Is the "mozilla-sync" plugin where sunbird should go?
> >
> >   
> mozilla-sync should already "almost" work with sunbird
> http://bluezync.kaarposoft.dk/

Ahh... thanks.  Is that the official home of the mozilla-sync plugin?
I was looking in the opensync svn and the tree looked pretty empty.

Looking at http://bluezync.kaarposoft.dk/0.1.6/building.html
it gives me the following command to grab the plugin:

svn co https://bluezync.svn.sourceforge.net/svnroot/bluezync/trunk/libopensync-plugin-mozilla libopensync-plugin-mozilla

But it looks like it's been moved?  Almost looks like I need to compile
bluezync to get it.

Am I on the right track?

- Chris

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

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

Chris Frey wrote:
>
>
> Thank you very much.  After I get google-calendar working, I was planning
> to look at sunbird.  I used to use that in 0.22, but I don't see that
> in 0.3x yet.  Is the "mozilla-sync" plugin where sunbird should go?
>
>   
mozilla-sync should already "almost" work with sunbird
http://bluezync.kaarposoft.dk/

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

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

On Fri, Jul 09, 2010 at 06:18:31PM +1200, Daniel Gollub wrote:
> You have now write-access to the google-calendar plugin.
> 
> So far you have access to:
> 
> /trunk (OpenSync)
> /plugins/kdepim
> /format-plugins/vformat
> /plugins/evolution2
> /format-plugins/xmlformat/trunk
> 
> and
> 
> 
> /plugins/google-calendar
> 
> Do you want to have access to some more plugins?

Thank you very much.  After I get google-calendar working, I was planning
to look at sunbird.  I used to use that in 0.22, but I don't see that
in 0.3x yet.  Is the "mozilla-sync" plugin where sunbird should go?

- Chris

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

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

On Friday 09 July 2010 05:35:34 pm Chris Frey wrote:
> I tried to commit some compile fix patches for the google-calendar plugin,
> but I'm getting a Forbidden message:
> 
> Sending        src/CMakeLists.txt
> svn: Commit failed (details follow):
> svn: Server sent unexpected return value (403 Forbidden) in response to
>  CHECKOUT request for
>  '/!svn/ver/5202/plugins/google-calendar/src/CMakeLists.txt'
> 
> Do I have access to the google-calendar plugin?  I seem to have access
> to evolution2, so I assumed I had access to most plugins.

You have now write-access to the google-calendar plugin.

So far you have access to:

/trunk (OpenSync)
/plugins/kdepim
/format-plugins/vformat
/plugins/evolution2
/format-plugins/xmlformat/trunk

and


/plugins/google-calendar

Do you want to have access to some more plugins?


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 05:39:09 pm Chris Frey wrote:
> So, if I understand correctly, on a system where xmlformat-event-doc
> exists, the first method will always succeed,

right.

> while the second one
> will fail if xmlformat-event-doc is disabled in the configuration
> for that particular group?

Nope, will fail if xmlformat-event-doc is disabled in the configuration for 
that pariticular member-plugin configuration.

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....?

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

On Fri, Jul 09, 2010 at 03:09:07PM +1200, Daniel Gollub wrote:
> 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

So, if I understand correctly, on a system where xmlformat-event-doc
exists, the first method will always succeed, while the second one
will fail if xmlformat-event-doc is disabled in the configuration
for that particular group?

Thanks!
- Chris

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

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

On Fri, Jul 09, 2010 at 03:12:23PM +1200, Daniel Gollub wrote:
> Please go ahead and apply those patches.

Thanks!

I tried to commit some compile fix patches for the google-calendar plugin,
but I'm getting a Forbidden message:

Sending        src/CMakeLists.txt
svn: Commit failed (details follow):
svn: Server sent unexpected return value (403 Forbidden) in response to CHECKOUT request for '/!svn/ver/5202/plugins/google-calendar/src/CMakeLists.txt'

Do I have access to the google-calendar plugin?  I seem to have access
to evolution2, so I assumed I had access to most plugins.

Thanks,
- Chris

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

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

On Friday 09 July 2010 03:12:23 pm Daniel Gollub wrote:
> 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.
> 

Oops, they're already in ... sorry for the late reply.

-- 
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