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

Re: [Opensync-devel] libsynthesis and vformats

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

Hello, to all of you.

Thank you for your time contributing to this discussion. I have to admit that I couldn't accomplish my goal to have a working sync with kde4 and my mobile, but I am very glad that all of you are discussing the future now.

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

I have not investigated the whole architecture of the library but just had a look here and then during my work on the akonadi plugin and the testing of libsyncml.

--- On Fri, 1/7/11, Chris Frey <cd...@fo...> wrote:

> > You're absolutely right - libsynthesis is not designed
> for generic sync.
> > Currently I also think that extracting the vformat
> (and rfc2822
> > btw.) handling and the script engine into more
> generically usable
> > libraries would be worthwhile.> 
> There has been a bit of talk about making a useful generic
> vformat
> library.  This would be useful for me as well.
> 
> I notice that there seems to be a difference in development
> and licensing
> strategies between OpenSync and libsynthesis.  Anyone
> can contribute
> to OpenSync and not have to sign anything, while it appears
> that
> contributing to libsynthesis requires signing a contributor
> agreement.
> This is off-putting to some developers.
> 
> I have some experience wrestling with vformat.c and
> incorporating it
> into the Barry plugin, as well as into the Barry library
> itself now.
> This is wasteful duplication, and it would be nice to see
> vformat
> support available generically.
> 
> Are you interested in any help with this that does not
> involve signing
> a contributor agreement?
> 

Licensing of synthesis was also my consideration. Interesting to know how Patrick has solved it into his project. I don't remember if I had to sign a license agreement when running syncevo the first time

kind regards


      

Re: [Opensync-devel] Gnokii patch

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

Hi, I could do the check in and have a look into the plugin.
I prefer c++ but in C were the first lesson in serious programming that I had back in 1990 ...

If you are familiar with object oriented programming (I think you are) and C++ think of C as if objects (C++) are structures (C) and methods (C++) are loose functions (C) so that everything in C is a function besides structures and variables. I hope this brief info helps you understand it.

Thank you for looking for alternatives I was wondering what this gnkokii thing was all about.

--- On Sat, 1/8/11, Quentin Denis <que...@gm...> wrote:

> There are also a sink and an easy slowsync issue to solve
> in gnokii_contacts.c 
> (and the same for gnokii_calendar.c) but before being able
> to fix this I would 
> need two questions answered:
> 
> 1. what is exactly a sink object and what is the concept
> behind it? Just a two 
> lines explaination please, I have a vague idea...

you can have one sync object type per config (notes, contacts, calendar and todo)

those are paired with the equivalent obj type on the other end(s)/plugin(s)

you assign one or more formats to an obj (like vtodo10/20 etc) on each side and the syncengine is doing the conversion and the sync between for you.

> 
> 2. it's my first time I code in C, but do the functions
> have to respond to a 
> particular constructor? Take the example of this outdated
> one:
> 
> void gnokii_calendar_get_changes(void *plugindata,
> OSyncPluginInfo *info, 
> OSyncContext *ctx)
> 
> which is only called by: 
> osync_objtype_sink_set_get_changes_func(event_sinkenv->sink,
> 
> gnokii_calendar_get_changes);

no, this way you assign a custom function to the object (in this case event_sinkenv->sink is associated with gnokii_calendar_get_changes) The code takes care for passing the right arguments to the function when called

> 
> no argument is passed, to I suppose it tells the engine to
> call the function 
> and to pass itself the required arguments? Hence the need
> to use a certain 
> standard constructor that I would have to take over from
> say the file-sync 
> plugin.

you can follow/borrow from this or any other ... the problem is in the details

> 
> There are also some objformat issues in that file, but I
> will try hard to 
> solve them lateron if nobody is willing to apply his/her
> expertise easily and 
> quickly. ;)
> 
> Best regards,
> Quentin (falling back on gnokii because of syncml issue:
> Ticket #1267)
> 

So your plan is to use gnokii with akonadi?

thanks and kind regards


      

[Opensync-devel] Gnokii patch

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

Here is a patch to make the gnokii plugin compile against the latest api. 
However, the plugin does not register yet and there are still warnings during 
compilation but I think this patch is a good starting point. Could anyone 
commit the changes since I have no access to svn?

There are also a sink and an easy slowsync issue to solve in gnokii_contacts.c 
(and the same for gnokii_calendar.c) but before being able to fix this I would 
need two questions answered:

1. what is exactly a sink object and what is the concept behind it? Just a two 
lines explaination please, I have a vague idea...

2. it's my first time I code in C, but do the functions have to respond to a 
particular constructor? Take the example of this outdated one:

void gnokii_calendar_get_changes(void *plugindata, OSyncPluginInfo *info, 
OSyncContext *ctx)

which is only called by: 
osync_objtype_sink_set_get_changes_func(event_sinkenv->sink, 
gnokii_calendar_get_changes);

no argument is passed, to I suppose it tells the engine to call the function 
and to pass itself the required arguments? Hence the need to use a certain 
standard constructor that I would have to take over from say the file-sync 
plugin.

There are also some objformat issues in that file, but I will try hard to 
solve them lateron if nobody is willing to apply his/her expertise easily and 
quickly. ;)

Best regards,
Quentin (falling back on gnokii because of syncml issue: Ticket #1267)

Re: [Opensync-devel] libsynthesis and vformats

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

On Wed, Jan 05, 2011 at 04:26:11PM +0100, Lukas Zeller wrote:
> You're absolutely right - libsynthesis is not designed for generic sync.
> Currently I also think that extracting the vformat (and rfc2822
> btw.) handling and the script engine into more generically usable
> libraries would be worthwhile.

There has been a bit of talk about making a useful generic vformat
library.  This would be useful for me as well.

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

I have some experience wrestling with vformat.c and incorporating it
into the Barry plugin, as well as into the Barry library itself now.
This is wasteful duplication, and it would be nice to see vformat
support available generically.

Are you interested in any help with this that does not involve signing
a contributor agreement?

- Chris

Re: [Opensync-devel] OpenSync: fragmentation is harmful

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

On Tue, Jan 04, 2011 at 05:12:39PM +0100, Michael Bell wrote:
> Perhaps we should shape the projects a little bit to not just discuss
> about a slow-moving development process but to understand the
> perspectives and challenges.
> 
> I know that usually such discussions are off list but a mailing list is
> a good archiving and transparent method. I hope you can accept this. So
> yes, I think it was the right decision from Patrick and Daniel to post
> this on the list.

Anyone who wishes to document OpenSync could use this format as well.
Start with the problems that need to be solved, and then show how they
are solved via the engine.

- Chris

Re: [Opensync-devel] [SyncEvolution] OpenSync: fragmentation is harmful

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

Hi Lukas,

On 01/05/11 16:26, Lukas Zeller wrote:
> 
> I mean, even we had perfect integration of SyncML, CalDAV, ActiveSync
> etc. today, I feel it would still not cover everyday sync needs I
> have today, let alone in the future. With the explosion of endpoints
> (devices) on one side and data sources (services, databases) on the
> other I doubt that point-to-point sync has a bright future. I have
> the impression what we need could be more similar to git than to
> SyncML.

I have the same feeling and therefore I created a playground - OldSync.
This is just a technology study. The idea was that there are some
basically good ideas like pipes, workflows and distributed repositories
(hg, mercurial) which preserve a history.

The idea was that every sync is a peer-to-peer sync but I always
synchronized a device or the filesystem with a filesystem. If the data
is in a repository (git, mercurial) then you have a backup and you can
synchronize in a distributed way (native git/hg push/pull).

Additionally such systems have a very flexible diff backends. So you
need normalization but not always an own merger (at minimum for text
based data).

> This is of course vague thinking and far from anything realizable in
> short term. But when talking about combining efforts, I think we need
> also to talk about the big context for all this.

I had just a rough idea too. I only want to express that I have the same
impression like you.

Best regards

Michael
-- 
___________________________________________________________________

Michael Bell                        Humboldt-Universitaet zu Berlin

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

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

Re: [Opensync-devel] [SyncEvolution] OpenSync: fragmentation is harmful

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

Hello all,

Coincidentally right now I am looking into what could be the long-term future of my efforts that went into libsynthesis, now that I am no longer with Synthesis, but again independent and "free" :-)

I very much welcome efforts to join forces to make sync better, as I must admit that despite all efforts in the last 10 years, interoperable PIM sync is still only a dream for most users. The only solutions that work for non-geeks that are not backed up by a corporate IT support are the (more or less) proprietary end-to-end solutions, all but interoperable.

At the same time I am convinced that standardized sync (far beyond PIM) is a concept that is of paramount importance for cloud computing. Selling our souls (ahem, data) to single points of (technical, commercial, political) failure such as Google, Facebook or even Dropbox can't be a long term solution. I see these as the Compuserves and Datex-P's of today, important to get things started. But if cloud computing is to be more than a hype, it will need a open, reliable, generic, pragmatic sync mechanism eventually, like inter-computer data exchange needed TCP/IP to take off.

So while I'm completely a SyncML guy as far as my actual work (libsynthesis) is concerned, the thing that brought me to SyncML in 2000 was the hope for truly interoperable sync, and not vice versa. Today, libsynthesis is certainly useful for doing SyncML, which will remain a part of picture for some years, if only to support legacy devices. But I'm totally open to ideas that go beyond SyncML, and probably refactoring libsynthesis to make parts of it more genererally usable (vXXX formatting in particular) for other protocols.

What I'm not sure at the moment at the concept level is if unifying the currently available (IMHO all more or less "legacy") sync protocols directly into a single engine is really the way to go. This thought feels a bit like creating the super-legacy engine. Maybe we need a structure where a really next gen sync mechanism builds the core, and the OpenSyncs, libsynthesises and Syncevolutions are degraded to plugins on an outer ring into that architecture to provide legacy sync.

I mean, even we had perfect integration of SyncML, CalDAV, ActiveSync etc. today, I feel it would still not cover everyday sync needs I have today, let alone in the future. With the explosion of endpoints (devices) on one side and data sources (services, databases) on the other I doubt that point-to-point sync has a bright future. I have the impression what we need could be more similar to git than to SyncML.

This is of course vague thinking and far from anything realizable in short term. But when talking about combining efforts, I think we need also to talk about the big context for all this.

Down from that meta level, two comments to messages in this thread:

On Jan 4, 2011, at 17:23 , Georg C. F. Greve wrote:

>> SyncML has had interoperability issues due to its loose definition.
>> Vendors also got stuck supporting the same old data formats and devices,
>> instead of adapting to more modern needs like iCalendar 2.0.
> 
> Both points are true. I would also say that SyncML has the conceptual flaw of 
> assuming dumber devices than todays devices actually are.

The devices might be faster and have more memory, but unfortunately some backends are still as dumb as ever regarding *the* (IMHO) single most important feature for smooth sync, especially when multi-point sync comes into the picture, which is a creator-assigned, 100% persistent UID.

SyncML tried to work around this, and most of the complexity and also of reliability issues in SyncML comes from the fact that identity has to be *derived* by comparing payload. And in consequence, this shifted resposibility for success or failure onto the loosely specified vXXX-formats, which were not designed for nor reliable enough for that (with the exception maybe of iCalendar 2.0 which most implementations don't have).

There's also a conceptual contradiction in this, because SyncML on one hand requires identity to be derived from the payload and on the other hand demands very much flexibility in handling of that payload (very dumb endpoints with very few fields vs. sophisticated endpoints with many details).
IMHO it's an either-or: Either identity is derived from payload (SHA checksums like in git or dropbox) which implies that all peers need to store the entire paylod 1:1, or identity is a (G)UID assigned by the creator of a record and guaranteed to remain unchanged over its entire lifetime - then peers might be allowed to only store abstractions or subsets of the actual data.

SyncML tried to do both at the same time - the price paid is the ever fragile slow sync with its potential for great duplicate mess.


On Jan 4, 2011, at 11:36 , Daniel Gollub wrote:

> I'm still open to adapt OpenSync and it's plugin to make more use of common 
> code - e.g. vcard handling of libsynthesis, maybe even seperating libsynthesis 
> in sometihng like libvxx to provide a common code base for vformats not only 
> for syncing application. I would be also happy if one day someone prepares 
> patches which replace OSyncEngine with something based on libsynthesis.
> 
> libsynthesis is definitely more mature code regarding vformat handling and the 
> engine with regards of syncml. Not quite sure with regards generic 
> synchronization.

You're absolutely right - libsynthesis is not designed for generic sync.
Currently I also think that extracting the vformat (and rfc2822 btw.) handling and the script engine into more generically usable libraries would be worthwhile.

Lukas

Re: [Opensync-devel] What can I do? Where could I start?

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

On Sun, 2 Jan 2011, Ope...@ca... wrote:
> I am interested in helping the OpenSync project.
>
> 20 years ago I was a fluent C developer.  Today I am a fluent bash scripter
> and would like to learn python.  I am effective at documentation.

Once you want to learn Python, I can and will help you
to get fast start if you're helping the Opensync project,
I've been writing it quite a bit, know something about
Web programming and Qt if needed (at least get you started).

I'm hanging in irc usually with nickname Tuju.


Tuju

-- 
I couldn't repair your brakes, so I made your horn louder.

Re: [Opensync-devel] OpenSync: fragmentation is harmful

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

Hi,

I need to catch up with the thread, but for now I want to answer to this here

--- On Mon, 1/3/11, Patrick Ohly <pat...@gm...> wrote:

> have). GPE is one example. Akonadi another. I already wrote
> a prototype
> backend for Akonadi, but now need a developer who is
> motivated to finish
> and maintain it.
> 

If you give me access to the code I could fix it, as I am highly motivated to have KDE4 sincable in near future (until someone fixes the rest of opensync).

For the rest I wish opensync could develop further, exactly because of its design - but I hope I'll answer later to the proper thread.

regards




      

Re: [Opensync-devel] OpenSync: fragmentation is harmful

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

Hi Patrick,

I think an important foot note is the question which goals the projects
have. I am personally (as IT manager of a university) see three general
needs in terms of synchronization:

1. a groupware server (with Active Sync support)
2. a sync solution on mobile devices (for Linux mobiles)
3. a local desktop solution to backup devices

A fourth nice-to-have need is a synchronization of a device with a
groupware server via a local software. This would avoid the usage of
over-the-air transport which sometimes still costs money. I think this
is some kind of bridge mode.

The first need is not the goal of OpenSync and SyncEvolution. The third
need is the goal of both solutions. So the question is which priority
have the other needs? Which general design ideas like plugins, engines,
formats or peer-to-peer exist and how does they perform in the different
use cases?

Disclaimer: The following answers just represent my actual limited
knowledge ;)

1.) SyncEvolution explicitly targets the second need.

2.) SyncEvolution can handle the fourth need but I think this was not
the usage which the developers have in mind.

3.) OpenSync is not primarily designed for the second need but it would
work. Just like SyncEvolution and the fourth need.

4.) OpenSync is definitely designed for the fourth need. A desktop
driven sync solution which makes the whole equipment happy in one step.

The numbers are just present to make referencing more easier. I know
these are simplifications but they are a good starting point for a
discussion ;)

So there are some important aspects beside the pure technology
(complexity vs. peer-to-peer). Such aspects are major use cases and
design priorities like user experience and usage philosophies.

Additionally I assume that nobody understand both software stacks
completely ;)

Perhaps we should shape the projects a little bit to not just discuss
about a slow-moving development process but to understand the
perspectives and challenges.

I know that usually such discussions are off list but a mailing list is
a good archiving and transparent method. I hope you can accept this. So
yes, I think it was the right decision from Patrick and Daniel to post
this on the list.

Best regards

Michael
-- 
___________________________________________________________________

Michael Bell                        Humboldt-Universitaet zu Berlin

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

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

Re: [Opensync-devel] OpenSync: fragmentation is harmful

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

On Di, 2011-01-04 at 14:11 +0100, Daniel Gollub wrote:
> Currently i don't see syncevolutaion is replacing OpenSync today. Maybe it 
> will some when in the future. Maybe not. It could disappear like other Sync 
> approaches due to various reasons. I'm not going to declare OpenSync as dead. 
> I highly recommend that OpenSync (Plugin) Developers decide by their own if 
> syncevoluation is a better alternative for them or not. It would be pretty 
> ignorant to say anything different. 

Fair enough. I've made my point, what kind of conclusions anyone draws
from it is that person's own choice. I'll answer the open questions
about SyncEvolution on the SyncEvolution mailing list and stop copying
the OpenSync list.

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

Re: [Opensync-devel] OpenSync: fragmentation is harmful

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

On Tuesday, January 04, 2011 12:42:55 pm Patrick Ohly wrote:
> Several reasons:
>       * libsynthesis did not (and still doesn't) fit into the OpenSync
>         architecture because engine and data conversion are closely
>         related. Arguably this is necessary, because one needs
>         information from the other (capabilities, choosing data
>         formats). Refactoring libsynthesis so that it fits into the
>         OpenSync plugin concept of formatters, backends and engine would
>         have been a major effort, both on libsynthesis and also
>         OpenSync.

Right. OpenSync is currently still working towards that until OpenSync or your 
or someone else solution full filled the goals OpenSync is targeting.


>         As you know, we discussed it at the time, but despite
>         all the emails that we exchanged I still did not fully
>         understand the OpenSync design and thus did not pursue this
>         further.

I see. I'm sorry about that ... I invested a lot of time in supporting you as 
much information i was able to do in my limited time ...

Synchronization is complex as you now. But this might also happen to 
SyncEvoluation that you will not get more contributors because nobody fully 
understand - beside you - how SyncEvoluation is designed.

For OpenSync, i haven't done the initial design - and also managed to 
understand most of the implementation without contributing major 
implementation like Armin and many others did.

So i just can give you the advice to make really really really good 
documentation. E.g. just having providing backend-samples is not enough.

For OpenSync Documentation of the internals will be very likely the next thing 
I'm going to do, to enable other people to finish 0.40.


>       * State of OpenSync. We needed a fully working solution within a
>         few months for Moblin 1.0 beginning of 2009. Two years later
>         there still isn't a stable OpenSync release, so I think the
>         decision was justified. I also don't think that investing work
>         into OpenSync would have led to a different result (pure
>         speculation, of course - we'll never know).

You need to contribute to projects if you want to gain something particular 
out of it.

> 
> > Something I'm very interested and also prepared several changes for, and
> > added  additional complexity, to introduce libsynthesis in OpenSync.
> > E.g. by making OpenSync independent of xmlformat.
> 
> Unfortunately refactoring libsynthesis is still blocking that, and there
> is no-one working on it. It simply isn't important enough because
> libsynthesis works well for its current usage.

I could imagine that it would be much more valuable for the FOSS community to 
re factor libsynthesis and OpenSync to have a lot common code base.

While developing OpenSync for several years i got in touch with a lot of 
people developing PIM interfaces. And there is so much redundant code which 
could be common code base. libsynthesis is very mature and well maintained 
code and would be much more of use for the FOSS community if it would be 
refactored. Which might be not important for you, but for other projects.



Currently i don't see syncevolutaion is replacing OpenSync today. Maybe it 
will some when in the future. Maybe not. It could disappear like other Sync 
approaches due to various reasons. I'm not going to declare OpenSync as dead. 
I highly recommend that OpenSync (Plugin) Developers decide by their own if 
syncevoluation is a better alternative for them or not. It would be pretty 
ignorant to say anything different.

My personal goal is to support the FOSS community so they have some tool to 
have a rock-solid synchronization solution. I will not declare OpenSync as 
dead in favor of SyncEvoluation. Not only because I'm not in position to 
declare the project as dead. Because I'm not convinced that SyncEvoluation is 
an alternative to OpenSync to date. And also because i have the impression 
that there are still lot of people which still want contribute to OpenSync and 
those I want to support with my contribution.

I doubt OpenSync is a "honey pot". Maybe your project is for various reason 
just not attractive enough. Maybe renaming it, like suggested by Chris would 
help.


The only harmful thing for both project is - discussing that fragmentation is 
harmful ;)

Instead each of us could concentrate on working towards their implementation 
make it just work.


-- 
Daniel Gollub
Linux Consultant & Developer
Mail: go...@b1...

B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

Re: [Opensync-devel] OpenSync: fragmentation is harmful

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

On Di, 2011-01-04 at 11:36 +0100, Daniel Gollub wrote:
> On Tuesday, January 04, 2011 10:04:39 am Patrick Ohly wrote:
> > > In summary, I would like to understand why you feel that redirecting our 
> > > efforts to SyncEvolution has any greater chance of success in solving the
> > > hard  problems of syncing.
> > 
> > My own summary, more at a meta level than the details above:
> >       * don't reinvent the wheel, use a mature engine (Synthesis)
> 
> 
> What was your reason choosing SyncEvolution and not OpenSync to adapt to 
> libsynthesis?

Several reasons:
      * libsynthesis did not (and still doesn't) fit into the OpenSync
        architecture because engine and data conversion are closely
        related. Arguably this is necessary, because one needs
        information from the other (capabilities, choosing data
        formats). Refactoring libsynthesis so that it fits into the
        OpenSync plugin concept of formatters, backends and engine would
        have been a major effort, both on libsynthesis and also
        OpenSync. As you know, we discussed it at the time, but despite
        all the emails that we exchanged I still did not fully
        understand the OpenSync design and thus did not pursue this
        further.
      * State of OpenSync. We needed a fully working solution within a
        few months for Moblin 1.0 beginning of 2009. Two years later
        there still isn't a stable OpenSync release, so I think the
        decision was justified. I also don't think that investing work
        into OpenSync would have led to a different result (pure
        speculation, of course - we'll never know).

> Something I'm very interested and also prepared several changes for, and added 
> additional complexity, to introduce libsynthesis in OpenSync. E.g. by making 
> OpenSync independent of xmlformat.

Unfortunately refactoring libsynthesis is still blocking that, and there
is no-one working on it. It simply isn't important enough because
libsynthesis works well for its current usage.

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

Re: [Opensync-devel] OpenSync: fragmentation is harmful

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

On Tuesday, January 04, 2011 10:04:39 am Patrick Ohly wrote:
> > In summary, I would like to understand why you feel that redirecting our 
> > efforts to SyncEvolution has any greater chance of success in solving the
> > hard  problems of syncing.
> 
> My own summary, more at a meta level than the details above:
>       * don't reinvent the wheel, use a mature engine (Synthesis)


What was your reason choosing SyncEvolution and not OpenSync to adapt to 
libsynthesis?

We wouldn't have any "fragmentation" if you would have chosen OpenSync, and 
not SyncEvoluation, to adapt it to libsynthesis.

Something I'm very interested and also prepared several changes for, and added 
additional complexity, to introduce libsynthesis in OpenSync. E.g. by making 
OpenSync independent of xmlformat.


I'm still open to adapt OpenSync and it's plugin to make more use of common 
code - e.g. vcard handling of libsynthesis, maybe even seperating libsynthesis 
in sometihng like libvxx to provide a common code base for vformats not only 
for syncing application. I would be also happy if one day someone prepares 
patches which replace OSyncEngine with something based on libsynthesis.

libsynthesis is definitely more mature code regarding vformat handling and the 
engine with regards of syncml. Not quite sure with regards generic 
synchronization.

And i guess OpenSync Plugin API is more mature then SyncEvolution Backend API. 
But would be interesting to hear if there is any flaw inside OpenSync, why it 
wasn't chosen to adapt to libsynthesis.


-- 
Daniel Gollub
Linux Consultant & Developer
Mail: go...@b1...

B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

Re: [Opensync-devel] OpenSync: fragmentation is harmful

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

Hello!

Let me add the SyncEvolution list, because the technical information may
be relevant. For those who see this for the first time, it started with
an open letter that I sent to the OpenSync list asking whether it really
still makes sense to continue with two different projects instead of
focusing on one:
http://sourceforge.net/mailarchive/forum.php?thread_name=20110103221846.GA21876%40foursquare.net&forum_name=opensync-devel

I was suggesting that SyncEvolution has the better baseline to continue
from. Of course this requires further explanation, which this email is
about. It is in reply to Graham because he raised several interesting
technical questions.

On Mo, 2011-01-03 at 16:57 +0000, Graham Cobb wrote:
> On Monday 03 January 2011 13:32:52 Patrick Ohly wrote:
> > In this email I'd like to appeal to the OpenSync developers to
> > reconsider whether keeping OpenSync around really helps Linux and open
> > source syncing. 
> 
> Patrick,
> 
> Thanks for your well considered thoughts.
[...]
> > Of course I am thinking of SyncEvolution here. It already works very
> > well for SyncML. I also have support for additional protocols, which I
> > will be able to publish soon. I think it would be worthwhile successor
> > of OpenSync, but obviously I'll need help to cover all the use cases
> > that you were shooting for with OpenSync.
> 
> I do not have a good feel for what SyncEvolution can and cannot do: can you 
> provide more information?  One thing is the device access protocols, of 
> course, but even if we all joined you and helped implement those, how would 
> SyncEvolution compare with what OpenSync is intended to do?  

SyncEvolution has grown organically over time (one could call it
evolutionary...), instead of shooting for a grand design covering
everything, like OpenSync did for 0.40. The main advantage is that there
have been regular stable releases since the very beginning four years
ago. On the other hand, features for which there was no real need yet
are still missing.

There have been different phases:
     1. SyncML client for Evolution
     2. SyncML client for additional storages (iPhone, Mac OS X, file)
     3. backends contributed by external developers (Ove Kaaven: N900
        calendar, Franz Knipp/m-otion.com: XMLRPC)
     4. SyncML server (direct syncing with phones), both via Bluetooth
        and HTTP, using the Synthesis engine
     5. non-SyncML protocols

The last point is the goal for SyncEvolution 1.2, in development right
now. It still uses the Synthesis engine and everything that it provides
(data conversion, conflict handling). SyncML is also still in use, but
only as internal protocol between two peers. What a developer above the
engine sees is the storage plugin (aka data source) interface.
Conceptually such a plugin must provide:
     1. change tracking (otherwise only slow syncs work)
     2. data import/export, either in the internal Synthesis format
        (field list) or in a backend specific text format that the
        engine understands

Further references:
      * introduction to the Synthesis engine and its data conversion:
        http://syncevolution.org/development/pim-data-synchronization-why-it-so-hard
      * convenience class for a data source which has id + revision
        string for each item and exchanges data as text:
        http://meego.gitorious.com/meego-middleware/syncevolution/blobs/master/src/syncevo/TrackingSyncSource.h
      * base class with maximum freedom:
        http://meego.gitorious.com/meego-middleware/syncevolution/blobs/master/src/syncevo/SyncSource.h
      * fully functional example backend:
        http://meego.gitorious.com/meego-middleware/syncevolution/trees/master/src/backends/file
      * configuration handling:
        http://syncevolution.org/development/configuration-handling
      * communication patterns and server mode:
        http://syncevolution.org/development/direct-synchronization-aka-syncml-server
      * local sync:
        http://www.mail-archive.com/syn...@sy.../msg01419.html

Ove and Franz were able to implement their backends with very little
assistance, so the documentation can't be that bad, although there's no
doubt that documentation could always be better.

> For example, does it only handle pair-wise sync?  If so, what is the 
> implication of that restriction (do you have to designate one of your devices 
> as master and sync everything else to it)?

Yes, sync is always between two peers. One storage should be the
designated "master" copy of the data. Any data which cannot be stored by
that "master" will get lost. The master could be in a capable system
like EDS or Akonadi, or in the file backend, which can store anything
that the sync engine itself can handle.

A sync topology is created by defining several of these 1:1
relationships. The master itself might be the client of another server,
as long as there are no loops. There is currently no logic for keeping
several of these peers in sync, but that could be added at a meta level
(keep syncing until all changes have been distributed).

Unknown extensions are currently dropped. This could be changed, but
leads to additional questions that would need to be sorted out: should
such extensions be sent to all peers, or just the one who created them?
What if different peers have a different understanding of "X-FOOBAR"?

It is safer to limit syncing to the data that is fully understood and
modeled in the Synthesis configuration file. Currently this covers vCard
3.0 + extensions and iCalendar 2.0 (including UID + RECURRENCE-ID,
VTIMEZONE, VALARM, but not attachments).

> Does it handle devices that have bugs or limited implementations (issues like 
> capabilities and merging)?

Yes. The Synthesis engine has dealt with that for 10 years and contains
a large collection of tools that can be used to deal with such problems,
ranging from different data profiles to a full scripting language that
can modify data on-the-fly. The Synthesis engine uses capability
descriptions to determine which properties are supported by an unknown
peer and has smart merging techniques for individual properties.

For example, consider the case where a VEVENT was modified like this:
     1. event in sync on peer A and B
     2. DESCRIPTION is extended on peer A
     3. SUMMARY is modified on peer B
     4. syncing recognizes the conflict and resolves it by using the
        SUMMARY of peer B (because the item on B is more recent) and the
        DESCRIPTION of A (because the description of B is a subset of
        it)

These two properties are handled differently because the conflict
resolution policy is configured differently to reflect the difference
between single-line and multi-line text.

>   What about missing unique IDs?

In such a case only slow syncs are possible. The Synthesis data modeling
defines which properties are compared to find pairs. The drawback of a
slow sync is that data removed on one side will be recreated.

I have thought a bit about that over Christmas, because I am now in that
situation: I can modify the address book on my FRITZ!Box 7390 router,
but it is an XML file with no unique identifier for each entry. My idea
is to do synchronization in multiple steps:
     1. keep a local mirror of all contacts
     2. do a slow sync against that mirror to find pairs; items in the
        mirror which have no corresponding entry on the router can be
        removed
     3. two-way sync between the mirror and my master data
     4. upload copy of the mirror to the router

The simpler alternative would be to pick some properties and use those
as key, perhaps with hashing to keep the key size small.

> Conflicts?

See above. Client-wins/server-wins/most-recent-wins are all
configurable. SyncEvolution itself uses most-recent-wins, with smart
merging of some properties.

>   And the 
> many other issues that OpenSync has been adding complexity while trying to 
> solve?

We would need to list those, but I'm fairly sure that much of it has
been considered already.

> In summary, I would like to understand why you feel that redirecting our 
> efforts to SyncEvolution has any greater chance of success in solving the hard 
> problems of syncing.

My own summary, more at a meta level than the details above:
      * don't reinvent the wheel, use a mature engine (Synthesis)
      * add features in small steps (more manageable, immediately
        useful)

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

Re: [Opensync-devel] OpenSync: fragmentation is harmful

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

On Mon, Jan 03, 2011 at 10:43:52PM +0100, Patrick Ohly wrote:
> Is OpenSync 0.4x alive today or vaporware? Is it recommended for
> production use?
> 
> Is OpenSync 0.22 alive and supported? I know that it works for some
> users and clearly SyncEvolution is no alternative to those users unless
> it implements the same features.

I'm not claiming that OpenSync is Hot Stuff.  I think its ideas are,
but the implementation still needs work.

What I'm trying to say is that before someone tries to kill OpenSync,
maybe the replacement should be Hot Stuff.  And if the replacement is
already Hot Stuff, then OpenSync will die of its own accord.


> > The project that is most useful and supports all useful features is
> > the one that deserves to keep going.  But in the meantime, I don't
> > believe there is any harm in having both.  It's the Linux way. :-)
> 
> The harm is that in the end, we end up with no project that really has
> the desired features.

There are lots of splits in the Linux world, and they can all be seen
as harmful in some way.  But that's how the free software world tends to
work.  I know, because even my own rather niche project has a competitor
(Barry and XmBlackBerry).  In the end, the world is a richer place
because users can choose which one works better for them.  The project
that works the hardest will get the farthest.

Whether OpenSync or SyncEvolution remains is beside the point.
In the last few months I haven't had time to work on OpenSync as I
would have liked, and so I wouldn't have been able to work on
SyncEvolution either.  Until one or both are able to clearly accomplish
the desired goals of syncing, both should remain.

If SyncEvolution turns out to be the winning project, more power to you!
Honestly. :-)  But doing that organically is the more stable path.

(I don't like using the term "winning", but we're talking about
projects that should be alive or dead too, so I think it's fair.)


> Here's the catch: without support from additional developers, some
> things will never get implemented because there are areas that I myself
> cannot or do not want to support (for example, devices that I don't
> have). GPE is one example. Akonadi another. I already wrote a prototype
> backend for Akonadi, but now need a developer who is motivated to finish
> and maintain it.
> 
> If everything already works and is implemented, why should I still want
> the support of the OpenSync developers? Clearly your skills would be
> wasted when focusing exclusively on maintenance.

I don't think that "It supports Akonadi!" is the feature I'm talking
about.  That matters for end users, but for developers who have invested
in OpenSync, what matters is that the future flexibility is there,
and that the same edge cases that OpenSync has planned for are planned
for in SyncEvolution.

So in that sense, it is the SyncEvolution "engine" that must compete
with the OpenSync "engine."  If both engines are theoretically capable
of supporting the same features, then it's just a matter of picking
the side with the most momentum.  If you can prove that, you'll have
a much easier time of killing OpenSync.

But to my understanding, there are theoretical engine differences
that need to be analyzed and thought about.  Does that make sense?
And I think Graham Cobb's questions were moving in that direction.
(Perhaps more profitably than my 2 cents.) :-)


> > (and maybe even change the name, since it sounds overly linked to
> > Evolution syncing)
> 
> I considered a name change, but rejected the idea because SyncEvolution
> already had a good page ranking and was well-known under that name at
> the time. I'm still reluctant to change it - too much uses the name
> (domain, command line tool). But if a name change is considered crucial
> despite the new interpretation of it ("the missing link"), then we can
> discuss it.

Well, I *should* know better, but I'm still discounting it in my head
by habit, because OpenSync from the beginning has aimed for Everything(TM),
while the name of SyncEvolution ties it to one small platform.

This is just an impression level issue, and has nothing to do with
what SyncEvolution can actually do.  But maybe users and developers
are getting that same impression?

Truth and clarity are more important than page rank, I think.
Page rank will follow.


> So far I have plenty of users, but only one additional developer (Ove
> Kaaven, for the N900 port). I can only speculate about the reasons, but
> I guess one of them is that OpenSync is still seen as the future for
> syncing on Linux. I hesitate to describe it with such a slightly
> disparaging comparison, but it is a bit like a honeypot that attracts
> new developers who then get stuck without ever getting nearer to a
> stable release of their work.

Honesty is the best policy. :-)  You could be right.

- Chris

Re: [Opensync-devel] OpenSync: fragmentation is harmful

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

On Mo, 2011-01-03 at 16:05 -0500, Chris Frey wrote:
> On Mon, Jan 03, 2011 at 02:32:52PM +0100, Patrick Ohly wrote:
> > Of course I am thinking of SyncEvolution here. It already works very
> > well for SyncML. I also have support for additional protocols, which I
> > will be able to publish soon. I think it would be worthwhile successor
> > of OpenSync, but obviously I'll need help to cover all the use cases
> > that you were shooting for with OpenSync.
> 
> My personal opinion is that the steps of your proposal are just slightly
> backwards.  I think that before we declare anything dead, that the
> replacement should first be just as much alive.

Is OpenSync 0.4x alive today or vaporware? Is it recommended for
production use?

Is OpenSync 0.22 alive and supported? I know that it works for some
users and clearly SyncEvolution is no alternative to those users unless
it implements the same features.

> So I'm also interested in the answers to Graham Cobb's questions.

That deserves a more in-depth reply. I'll do that tomorrow.

> The project that is most useful and supports all useful features is
> the one that deserves to keep going.  But in the meantime, I don't
> believe there is any harm in having both.  It's the Linux way. :-)

The harm is that in the end, we end up with no project that really has
the desired features.

> In other words, if you want the support of the OpenSync developers
> (such as it is), implement OpenSync's features in SyncEvolution

Here's the catch: without support from additional developers, some
things will never get implemented because there are areas that I myself
cannot or do not want to support (for example, devices that I don't
have). GPE is one example. Akonadi another. I already wrote a prototype
backend for Akonadi, but now need a developer who is motivated to finish
and maintain it.

If everything already works and is implemented, why should I still want
the support of the OpenSync developers? Clearly your skills would be
wasted when focusing exclusively on maintenance.

> (and maybe even change the name, since it sounds overly linked to
> Evolution syncing)

I considered a name change, but rejected the idea because SyncEvolution
already had a good page ranking and was well-known under that name at
the time. I'm still reluctant to change it - too much uses the name
(domain, command line tool). But if a name change is considered crucial
despite the new interpretation of it ("the missing link"), then we can
discuss it.

> and you'll win automatically.  You won't need
> proposals.  You'll have the features, and therefore the users *and*
> the developers.

So far I have plenty of users, but only one additional developer (Ove
Kaaven, for the N900 port). I can only speculate about the reasons, but
I guess one of them is that OpenSync is still seen as the future for
syncing on Linux. I hesitate to describe it with such a slightly
disparaging comparison, but it is a bit like a honeypot that attracts
new developers who then get stuck without ever getting nearer to a
stable release of their work.

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

Re: [Opensync-devel] OpenSync: fragmentation is harmful

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

On Mon, Jan 03, 2011 at 02:32:52PM +0100, Patrick Ohly wrote:
> Of course I am thinking of SyncEvolution here. It already works very
> well for SyncML. I also have support for additional protocols, which I
> will be able to publish soon. I think it would be worthwhile successor
> of OpenSync, but obviously I'll need help to cover all the use cases
> that you were shooting for with OpenSync.

My personal opinion is that the steps of your proposal are just slightly
backwards.  I think that before we declare anything dead, that the
replacement should first be just as much alive.  Alive in the sense
of features.  Otherwise people will just continue hacking on the
design they like best.

So I'm also interested in the answers to Graham Cobb's questions.
If there is something that OpenSync can do today that SyncEvolution
can't, then that should be fixed before OpenSync dies.

The project that is most useful and supports all useful features is
the one that deserves to keep going.  But in the meantime, I don't
believe there is any harm in having both.  It's the Linux way. :-)

In other words, if you want the support of the OpenSync developers
(such as it is), implement OpenSync's features in SyncEvolution
(and maybe even change the name, since it sounds overly linked to
Evolution syncing) and you'll win automatically.  You won't need
proposals.  You'll have the features, and therefore the users *and*
the developers.

- Chris

Re: [Opensync-devel] OpenSync: fragmentation is harmful

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

On Monday 03 January 2011 13:32:52 Patrick Ohly wrote:
> In this email I'd like to appeal to the OpenSync developers to
> reconsider whether keeping OpenSync around really helps Linux and open
> source syncing. 

Patrick,

Thanks for your well considered thoughts.

I am a small (although fairly long term) contributor to OpenSync, and I have 
no particular desire to continue it if it is not going to be successful or 
there is a better alternative.  Of course, I realise there are others who have 
invested much more time and effort than I have, for which I am extremely 
grateful, and who may feel much more strongly about it than I do.

Speaking personally, my desire is to be able to synchronise my various devices 
and services, which include SyncML devices (of various flavours, each with 
their own quirks, bugs and features), GPE (which I continue to support), KDE 
(kontact) and Outlook/Exchange (for which I have limited, one-way support 
using flat files and OWA).  I am happy to contribute to a project which has a 
reasonable prospect of supporting those various devices.

I have learnt, over the years, that syncing is much harder than it appears at 
first sight!  I will admit that I no longer fully understand the OpenSync 
architecture and design so I can't really comment on your view that it is too 
complex and will not achieve its goals.

I do feel that the plugin API, and the format convertors, seem to be largely 
useful.  Certainly for the GPE plugin it is not too hard to implement the 
required API and it seems to include pretty much the things that are likely to 
be required.  I suspect that both discovery and capabilities may be over-
complex, and I also think the flow-control (memory usage, timeout) problem is 
still not solved (which is partly my fault as I tried to solve it!).  But the 
basic plug-in architecture seems useful and I do wonder whether any of it 
could be re-used.

> Of course I am thinking of SyncEvolution here. It already works very
> well for SyncML. I also have support for additional protocols, which I
> will be able to publish soon. I think it would be worthwhile successor
> of OpenSync, but obviously I'll need help to cover all the use cases
> that you were shooting for with OpenSync.

I do not have a good feel for what SyncEvolution can and cannot do: can you 
provide more information?  One thing is the device access protocols, of 
course, but even if we all joined you and helped implement those, how would 
SyncEvolution compare with what OpenSync is intended to do?  

For example, does it only handle pair-wise sync?  If so, what is the 
implication of that restriction (do you have to designate one of your devices 
as master and sync everything else to it)?

Does it handle devices that have bugs or limited implementations (issues like 
capabilities and merging)?  What about missing unique IDs?  Conflicts?  And the 
many other issues that OpenSync has been adding complexity while trying to 
solve?

In summary, I would like to understand why you feel that redirecting our 
efforts to SyncEvolution has any greater chance of success in solving the hard 
problems of syncing.  

By the way, I do agree with your analysis of Buteo -- at the MeeGo summit it 
became clear that Buteo is not trying to solve the sync problem, it is more 
like a scheduler and manager.

Graham

Re: [Opensync-devel] OpenSync: fragmentation is harmful

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

On Monday, January 03, 2011 02:40:21 pm Patrick Ohly wrote:
> On Mo, 2011-01-03 at 14:32 +0100, Patrick Ohly wrote:
> > I considered writing this as an open letter, but rejected the idea
> > because I didn't want to make OpenSync look bad in public. Please let me
> > know what you think.
> 
> ... but then Daniel encouraged me to send it publicly. I meant to
> explain that, but then forgot to edit this paragraph when resending.

Thank you for sending it publicly!

-- 
Daniel Gollub
Linux Consultant & Developer
Tel.: +49-160 47 73 970 
Mail: go...@b1...

B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

Re: [Opensync-devel] OpenSync: fragmentation is harmful

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

On Mo, 2011-01-03 at 14:32 +0100, Patrick Ohly wrote:
> I considered writing this as an open letter, but rejected the idea
> because I didn't want to make OpenSync look bad in public. Please let me
> know what you think.

... but then Daniel encouraged me to send it publicly. I meant to
explain that, but then forgot to edit this paragraph when resending.

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

[Opensync-devel] OpenSync: fragmentation is harmful

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

Hello OpenSync project!

As you know, I have been watching your project for a while, before and
in parallel to working on SyncEvolution. I've explained my motivation to
work on SyncEvolution already (different architecture, build something
in incremental steps, release usable code often), so I won't repeat that
here.

In this email I'd like to appeal to the OpenSync developers to
reconsider whether keeping OpenSync around really helps Linux and open
source syncing. My impression is that all efforts to put the project
back on track have failed. I also think that they'll continue to fail,
because the design is too complex. Michael has already published his
thoughts on that when he announced that he would step down as maintainer
of the SyncML plugin, and I have little to add to that.

In the meantime, new developers show up who want to help. Some of them,
like Emanoil, put in significant effort that doesn't benefit anyone
because the rest of the system still doesn't work.

There are precious few developers who still care about syncing; IMHO
spending their time on OpenSync weakens other projects who still have a
chance of solving the problem as a true open source project.

Of course I am thinking of SyncEvolution here. It already works very
well for SyncML. I also have support for additional protocols, which I
will be able to publish soon. I think it would be worthwhile successor
of OpenSync, but obviously I'll need help to cover all the use cases
that you were shooting for with OpenSync.

In case you wonder about Buteo: I have done an extensive analysis of it
and can assure you that it is not a replacement for the Synthesis engine
+ SyncEvolution, by design. For example, it does not include data
conversion support. The existing open source plugins are merely examples
that are meant to be modified by anyone who wants to support a specific
peer. Who is doing that work for the open source part is currently open
(see bugs.meego.com #5468). Direct synchronization with phones isn't even
meant to be a supported feature yet (not requested for meego.com).

So my proposal is this: 
      * officially declare OpenSync dead, to avoid distracting new
        developers and users 
      * point towards SyncEvolution as an alternative 
      * work with me on improving SyncEvolution so that it fits your
        needs; we could meet at FOSDEM this year to have a face-to-face
        meeting about next steps or meet online earlier

I considered writing this as an open letter, but rejected the idea
because I didn't want to make OpenSync look bad in public. Please let me
know what you think.

Disclaimer: I will not gain anything from expanding the scope of
SyncEvolution. Quite the opposite, I expect to have a lot more work at
my hands if you accept. So if you want to do me a favor, reject the
proposal ;-}

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

Re: [Opensync-devel] What can I do? Where could I start?

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

Hi Charles,

Let me welcome you to the OpenSync developers team! Since I am the
first to reply on your mail, please consider my suggestions as being
personal ones. In fact, the OpenSync team has suffered severe
management issues and lacks some dynamic today because of outdated
scheduling and lost objectives or motivation. Therefore we don't have
a clear roadmap for now. Emanoil and myself are the newest member of
the team and together with Chris Frey we try to reorganize the project
and to redefine objectives.

So far to the introductory status update. In my opinion, the most
important things to work on today are the following:
- fix the slow sync issue in the core engine
- port the missing plugins from API 0.22 to 0.40 (gnokii, etc...).
There is a guide written by Chris somewhere in the wiki and the
mailing-archives.
- decide how we solve the SyncML issue: libsyncml, libsynthesis or Buteo

Maybe there is still work to do on the documentation, I did not check
this out, but the Wiki certainly needs a refresh/update of its
content!

I hope this gives you a good start, more will follow from the active
developers once they are available again!

And after all, happy new year!

Best regards,
Quentin

On Sun, Jan 2, 2011 at 1:53 PM,  <Ope...@ca...> wrote:
> Hello  :-)
>
> I am interested in helping the OpenSync project.  I have read the
> http://www.opensync.org/wiki/join/developer page and the pages it links.  I
> have browsed the last ~18 months of opensync-users and opensync-devel.  Now
> I am wondering what to do next.
>
> 20 years ago I was a fluent C developer.  Today I am a fluent bash scripter
> and would like to learn python.  I am effective at documentation.
>
> There is a huge amount to learn to get up to speed with a project the size
> of OpenSync.  Where to start?  Are there any relatively self-contained
> components that need documenting so I could both begin familiarisng and
> contribute?
>
> Best
>
> Charles
>
>
> ------------------------------------------------------------------------------
> Learn how Oracle Real Application Clusters (RAC) One Node allows customers
> to consolidate database storage, standardize their database environment, and,
> should the need arise, upgrade to a full multi-node Oracle RAC database
> without downtime or disruption
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Opensync-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensync-devel
>

[Opensync-devel] What can I do? Where could I start?

[<Ope...@ca...>]

Hello  :-)

I am interested in helping the OpenSync project.  I have read the
http://www.opensync.org/wiki/join/developer page and the pages it links.  I
have browsed the last ~18 months of opensync-users and opensync-devel.  Now
I am wondering what to do next.

20 years ago I was a fluent C developer.  Today I am a fluent bash scripter
and would like to learn python.  I am effective at documentation.

There is a huge amount to learn to get up to speed with a project the size
of OpenSync.  Where to start?  Are there any relatively self-contained
components that need documenting so I could both begin familiarisng and
contribute?
 
Best      

Charles

Re: [Opensync-devel] *.opensync.org server maintenance

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

On Saturday, December 18, 2010 10:32:56 am Daniel Gollub wrote:
> I'll let you know once the migration is done.

*.opensync.org is up again (incl. DNS update).

The CDash instance is not yet migrated.

If there is any problem with trac or subversion of OpenSync, libsyncml or 
libwbxml just let me know via private mail.

Best Regards,
Daniel

-- 
Daniel Gollub
Linux Consultant & Developer
Mail: go...@b1...

B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537