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