Re: [Opensync-users] Where to start?

[Martin O. <doc...@gm...>]

> It has already been decided that libopensync is a sync engine tying 
> format and connection plugins together. Other projects are free to
> implement upper layers and utilize libopensync as such engine.

The only problem I can see is one of position. If a project does not
expect to be used in a certain way it won't provide the required APIs or
be orientated in such a way as to make creating those other layers
impossible.

For instance the config files in 0.3x slaughter the possibility of
hardware detection and hal integration without having hackish glue.

While I can agree that small blocks are a good idea, if one of your
interfaces is expected to be hardware, you should at the very least
expect hal integration in other layers and understand what that means.
and at most lay groundwork for supporting it.

> Not sure. I do know that there are projects that somewhat overlap with this, implementing 
> their own sync engine and GUI, all those hw detection layers etc. 
> But imo it's good to have stuff in smaller chunks and keep simple 
> interfaces between those.

I'm going to be working on peer access, I believe it's more important
than syncing at the moment. An important divide into smaller blocks
would have been one project to provide data access another to do format
translation and yet another to provide syncing logic.

Providing a singular use case scenario from which developers/users can
build outwards may have been a better strategy than building as wide a
base of support without an end to end stack;

1) Hardware Detection (HAL)
2) Hardware Data Access (Unknown, Various, OpenSync)
3) Online Detection (Network Manager)
4) Online Services Access (Unknown, various, OpenSync)
5) Syncing (OpenSync, Conduit)
6) GUI Integration (Conduit Some)

We're no were near delivering something useful to users looking at end
to end stack.

Regards, Martin