[Kde-pim] SyncML meeting - conclusions

[Riccardo Iaconelli]

On Friday 04 June 2010 12:52:49 Sascha Peilicke wrote:
> On Friday 04 June 2010 11:11:24 you wrote:
> > Hi,
> > since the meeting has been quite messy for various reasons, I offered to
> > provide a little summary for everyone on how things went.
> > 
> > After some discussion on the frameworks and on the various possibilities
> > we had, we reached some kind of consensus on the following proposal,
> > done by me. I report it here for further (eventual) discussion.
> 
> Uhm, at least a consensus with some actors missing. This proposal (done by
> you) makes me feel like being stabbed in the back literally, that
> 'consensus' must have happened after I quit the meeting. But let's have a
> look at things one after another. This mail is intended to express that
> there is no such consensus and maybe I should excuse in advance to the
> list as this response was written with a bit of a temper. Actually I'm not
> in the mood of starting a flamewar but not responding to this mail could
> lead to a lot of question marks regarding the current state of SyncML for
> KDE.

Sorry, it did not mean to sound that way. :)

First off, as my mail says, and as I just told you on IRC, there was *some 
kind* of consensus, not an universal consensus. That's the main reason why in 
the first place I decided to take the discussion to a mailing list.

Maybe I should state it better - the participants to the discussion, at the 
time we reached that agreement were (in no particular order):

mzanetti, kfx, drf, saidinesh5, ruphy, atomopawn, vkrause, mschnide, krake, 
phoenixx, SeyZ.

> I'll try to sum up the current situation for all those that don't follow
> that topic to closely. Currently there are several attempts on getting
> SyncML support for Akonadi. One of those was a GSoC project done by me
> based on a successful experience with Qtopia. The outcome of the project
> was a near- working solution which is not stable enough to be reliably
> used.
> 
> > The plan:
> > 
> > - Akunambol
> > The plan would be to use Akunambol as main KDE syncing solution. What it
> > would provide is user interaction, an interface, an autosyncer and stuff
> > like that. It will also provide an abstract interface to load backends
> > (syncevo or funambol, or eventually more in the future) ala phonon. We
> > already asked Dario Freddi for some insight on this and he says that,
> > given our requirements, it's easily feasible.
> 
> Those plans for Akunambol are all nice and neat and I support those.
> Nonetheless is currently not anywhere near being 'the main KDE syncing
> solution'. As I said towards the end of the meeting, such a plugin
> mechanism may be hard if not impossible to realize as the feature sets of
> both backends differ a lot. Such plugins would have to provide these
> feature sets and your front end app (Akunambol) would have to
> enable/disable large parts of the UI code.

Well, really not. SyncEvolution only adds, as new feature, syncing to phones. 
This means conditionally enabling one button, and eventually a tab, in the 
configuration options. It doesn't really seem as a large part of the UI code.

> And it may not even make sense
> as all SyncEvo is a superset of Funambol, where the former (AFAIK) still
> provides an API that is similar to the latter.

So what? I mean, good, it will be easier to create a SyncEvolution source. :)

> It is understandable that
> you don't want to scrap your baby to go for a different (but superior)
> solution.

So much superior that it's years that you're struggling to create a KDE 
client, right? Aaanyways, I really don't appreciate this kind of sentences, 
and it's getting off topic.

It's really neither about funambol nor about syncevolution, it's about sharing 
code and avoid uselessly splitting the community. :)

To make myself more clear, I *am* willing to put funambol aside at a certain 
point. I simply think that doing it now is silly, since it's the only thing 
that works.

> I've had a look at the current code base again and besides that
> it is failing to build (with recent funambol packages)

that's a problem in makefiles of a specific funambol release, and I already 
told you how to fix it. Let's not debate on these details please.

> that gui is
> currently little more than a 'sync now' button. And it is only contacts by
> now. Nonetheless I'm all for developing it further but don't try to
> over-advertise it.

AND a KCM module AND an autosyncer. Sure, it's a 0.1. And sure, it's not 
amarok, but do you really want much complexity in an interface? There's much 
work to do, but all in the direction of not getting in your way.
Anyways, why reinventing the wheel? :)

> Besides there are other already successful 'KDE sync
> solutions' like KPilot.

Now, *this* is off-topic. Are you suggesting we should move everything into 
kpilot? ;-)

> > - Funambol
> > This is the backend that we have already ready, and which works well. It
> > is not capable to directly sync a phone via bluetooth but is quite solid
> > for standard web usage. It will be, at least at the beginning, the
> > default backend which will ship with akunambol.
> 
> My impression is that somehow repeating all the issues we faced (and the
> reason for which SyncEvolution exists after all) are ignored again and
> again. This includes all the talks and mails that where kindly provided by
> Patrick Ohly, our local SyncML-guru, as well as the experiences i've got
> (which includes a working solution for Qtopia). Anyways I'm tired of
> repeating myself.

It still doesn't say me anything concrete on which we could share work, 
besides "please trash all your efforts, funambol is crap".

To quote some of the things you said me on IRC:

---

<saschpe> because joining forces means a different thing for you than to me. 
and you've got a way of not hearing or reading what others read or write. 
instead you insist on turning everybody onto your side. so I start again 
repeating myself. and again. that's fruitless. so let's simply end that 
discussion here

<saschpe> I meant -others write-

<saschpe> so in that sense, I'll leave the channel for now. good luck for 
Akunambol nonetheless.

<saschpe> cya

<ruphy> saschpe: what does it mean for you then? i really haven't seen a 
concrete proposal from you... while i proposed a compromise

<ruphy> saschpe: i'm open to options, please give me a concrete thing though 
:)

[some delay...]

<-- saschpe (~saschpe at mgdb-4d0cfda0.pool.mediaWays.net) has quit (Read error: 
Connection reset by peer)

---

As I said, if you want to reinvent everything, it's terribly sad, but okay. 
But then don't accuse me of not listening to you.

But really, maybe I still haven't made my point correctly maybe I phrased it 
better on IRC. Let me quote myself:

i'm not saying "everyone drop what you're doing"
i'm saying: everyone keep working on syncevo, I'm abstracting akunambol so 
that it becomes backend-agnostic
so that akunambol gets a well working backend, one which works in a lot of 
different situtation (syncevo), and can be shipped with KDE SC
and syncevo gets a native KDE GUI
funambol will be another backend, a needed one certainly, but not necessairly 
the main one. something, after all, will be needed to develop akunambol, at 
least now, and we can already ship funambol with akunambol for early testing 
purposes.

> > - GSoC and SyncEvolution
> > Dinesh agreed that he will continue working on the SyncEvolution backend.
> > Since he is just getting familiar with the code, we agreed that instead
> > of replicating things and starting a new interface, he would just code
> > an Akunambol backend, which can be shipped with akunambol when it's
> > ready, and that the users can choose and load at runtime.
> 
> That's not yours to decide and at the same time crap.

Infact it was Dinesh telling me that it was a good idea. :)

> There won't be such
> thing as an Akunambol backend. There will be a SyncEvo Akonadi backend as
> stated in the GSoC proposal. There's no such thing as 'replecating
> interfaces', there's a (mostly) well-defined mechanism to create new
> backends for SyncEvo, that what he's going to utilize.

But a KDE GUI for syncevo is missing, right? So what about using Akunambol, 
once the SyncEvo backend is done? What do you gain in loosing help and 
manpower from the Akunambol guys?

> [...]
> > Me, Sandro Munda(?) and Micheal Zanetti will continue working on
> > akunambol, leaving the rest of the guys able to concentrate on
> > syncevolution and KDE integration.
> 
> That's the most sensible idea so far and I support that. This implies that
> everything will stay as it was before that ill-fated 'meeting'. Dinesh will
> continue to concentrate on his GSoC, which actually just started, and you
> guys can work on Akunambol. I for myself started an initial KDE frontend
> for SyncEvo which I intend to put into Ravi's hands. That will be based on
> SyncEvo's D-Bus interface alone and will reuse some stuff I had already
> for user and config profiles. Whatever turns out to be the most feasible
> solution, that may become 'the main KDE sync solution' maybe. Or maybe
> it's several solutions with different scopes, how knows.

Please don't waste precious manpower. It's probably one of the things we need 
most in KDE. :)

Bye,
-Riccardo
-- 
Pace Peace Paix Paz Frieden Pax Pokój Friður Fred Béke 和平
Hasiti Lapé Hetep Malu Mир Wolakota Santiphap Irini Peoch שלום
Shanti Vrede Baris Rój Mír Taika Rongo Sulh Mir Py'guapy 평화
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/