Re: [Opensync-devel] Fixing the OpenSync core development BUS factor

[Daniel G. <go...@b1...>]

On Tuesday 20 October 2009 12:31:06 am Paul Eggleton wrote:
[...]
> I'm not quite sure how to decide which areas I would work on in the core;
>  as you say there is great temptation to take on the areas that are most
>  important to me as a plugin developer. I agree though that that will
>  ultimately not solve anything.
> 
> I have some hesitation in doing this, but perhaps if I can take these two
> 
> items for now:
> >  - Synchronization Engine (workflow of the Synchronization: connect,
> >    get_changes, ...)
> >    * documentation
> >    * cleanup
> >    * maintenance
> >    * bugfixing
> >    * profiling
> >  - Format Conversion (abstract logic to convert formats, e.g. conversion
> >    pathes, ...)
> >    * review of the conversion path building process
> >    * profiling
> >    * documentation
> 
> I don't know if we have much time for profiling at the moment :)

Yeah profiling is not so critical today ... we might do this with version 0.99 
or so ;)

> Bugfixes
>  and understanding & documenting the process are a lot more important right
>  now.

ACK

>  I am still also ready to do fixes and completion of the API
>  documentation in any of the areas required, but what I am usually lacking
>  there is understanding about how some of the functions should work.
[...]

The easiest thing for me would be that you start with how the application API 
get used - e.g. osynctool - or convtool (from vformat plugin - for format 
conversion).


For Engine the public API function are acutally just those:

osync_engine_new()
osync_engine_initiazile()
osync_engine_synchronize_and_block() <- this is doin' the entire sync
osync_engine_finalize()
osync_engine_unref()

So i would suggest you start looking into osync_engine_initiazile() and 
osync_engine_synchronize_and_block() ... there are also some junks in the 
OpenSync how the inner engine works.

As soon you have question drop a mail on opensync-devel@

Maybe for the beginning you could try to find out the order of the plugin 
calls in the engine - e.g. connect(), disconnect(), get_changes() ... and so 
on ... once you find your way through that it's quite easy to find throught 
the stack from engine call to the plugin call...

Best Regards,
Daniel


-- 
Daniel Gollub                        Geschaeftsfuehrer: Ralph Dehner
FOSS Developer                       Unternehmenssitz:  Vohburg
B1 Systems GmbH                      Amtsgericht:       Ingolstadt
Mobil: +49-(0)-160 47 73 970         Handelsregister:   HRB 3537
EMail: go...@b1...          http://www.b1-systems.de

Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg
http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D