[akunambol] Re: API design - FunambolSyncSource

Marco Garatti garatti at funambol.com
Wed Jan 26 23:52:55 CET 2011


Hi Riccardo,

I must admit I do not fully understand the proposal, so my comments may be 
misplaced.

My understanding is that the "main" class of the plugin is something that 
provides at least the following methods:

1) void performSync()
2) QWidget* getConfigurationWidget()

These methods allow the engine to trigger a sync for a particular type of 
data. Therefore there must be a plugin for each type of data. For example 
there would be a plugin to sync contacts with Funambol and possibly another 
plugin to sync calendars with Google.
The missing piece is the global configuration for the single service. For 
example there should be a single point where Funambol or Google credentials 
are entered (and not one for each type of data).
This could be addressed by having two separate entities:

1) the account (an account is bound to a service. You have an account on 
Google and one on Funambol for example)

2) the type of data associated to each account. You can have sevaral type of 
data associated to the same account (e.g. contacts and calendar).

A plugin could then expose several different classes. One is responsible for 
the account management (for example it validates the user credentials), while 
the others are responsible for one type of data each.

Once this is defined, we can start to think about the architecture of each 
single plugin and see what is the best approach.

Hope this makes sense :)

Cheers,
Marco

On Saturday, January 22, 2011 01:02:39 pm Riccardo Iaconelli wrote:
> Hi,
> to get to some interesting details, today I finally managed to get back
> writing some code. To be precise I worked on the FunambolSyncSource class,
> implementing configuration handling the way Funambol requires it.
> 
> Now, I am working on integrating a Funambol::SyncSource. The first idea was
> to wrap it into FunambolSyncSource like I'm doing with the config, so
> essentially hiding the needed multi-classes code from the developer - but
> then I thought that there is a much cleaner approach, even if it requires
> one more class for the plugin developer.
> 
> The idea would result in code similar to this:
> 
> - A (minimal) class, the "manager", subclass of FunambolSyncSource, "main"
> class of the plugin.
>  - Handle some "cosmetic" details, so e.g.
>    - in the constructor, do things like:
>      setSourceUID("plasma-contacts")
>      setMimeTypeSync("text/x-vcard")
>      setRemoteURI("contacts")
> 	 ...
>    - take care of creating a QWidget for configuration
>    - return a valid QString for the UI
>    - ...
> 
> - Another class, subclass of FunambolBackend (random name), which is itself
> subclassing Funambol::SyncSource, that only takes care of getting and
> writing data, reimplementing methods such as:
>   - void getItem(uid)
>   - void deleteItem(uid)
>   - void removeAllItems()
>   - ...
> 
> In the FunambolSyncSource class you would then do something like:
> 
>     this->setBackend(new PlasmaContacts);
> 
> where PlasmaContacts inherits FunambolBackend.
> 
> Thoughts? I think that this leads to cleaner and easier to write code, even
> if it requires the plugin developer to write two classes. The "manager"
> class would become pretty small and I suppose it would be easy to add
> multithreading to the sync process. Do you think it's a good idea?
> 
> You can check out the relevant code in akunambol/library.
> 
> Bye,
> -Riccardo


More information about the akunambol mailing list