|
From: Emanoil K. <del...@ya...> - 2011-01-08 13:12:48
|
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
|