[trunk] Last API Changes for 0.3x/0.40 / close to a freeze...

[Daniel Gollub-2]

Hi,

Björn and I do currently the last API cleanups. The python wrapper is
currently not building due to all this changes. The wrapper doesn't have high
priority as stabilizing the (C) API. (It's up for takers if someone wants to
port the wrapper ... otherwise i'll do that right before tagging 0.39).

Since this are lots of API changes - i try to make this quick and painless for
you. So please standby till Monday. I hope to to get everything inside SVN
this night. Only #1013 and #1084 might take more time.

Why we do all those changes now?
Because we hope to not break the API in near future at all... and make things
stable for plugin/application development.

As soon as listed things are done i'll provide patches for all plugins I'm
able to build. If you want to port your plugin on your own - and have any
questions or problems. Don't waste time and feel free to contact me
immediately - or try to catch Björn on IRC ;)

For those who don't hesitate to contribute to /trunk - please assign a ticket
to yourself from this query:
http://www.opensync.org/query?status=assigned&status=new&status=reopened&group=status&milestone=OpenSync+0.39


Currently on our API breaking list:

[API] OSyncObjTypeSinkFunctions struct from public API/headers
http://www.opensync.org/ticket/1086

This struct is the last public struct in the API. For API maintenance reason i
would like to remove this to make the API more stable. This requires
modifications on all sync plugins.

-

[API] Drop osync_objtype_set_slowsync() and add parameter osync_bool *slowsync
to plugin connect()
http://www.opensync.org/ticket/1085

There were some ongoing discussion on IRC between Michael and Bjöern after
review i discovered a Bug inside OpenSync and the connect_done() handling
(which is fixed already). And to make things clear i plan to put this change
on the API break list.

-

[API] Common API interface pattern for list-implementations
http://www.opensync.org/ticket/975

Björn is working on that.

-

[API] size_t/unsigned int review and cleanup
http://www.opensync.org/ticket/974

This is currently up for takers - please start with public APIs. Internal APIs
we can fix later (after 0.39). This means review all headers which get
installed and parameter lists of functions which start with OSYNC_EXPORT.

-

Make OSyncCapabilities and the use of Merger/Demerge format independent
http://www.opensync.org/ticket/1084

Still need to finish my "design" draft. As soon this is ready i'll drop a new
mail about this. I already started to make some notes in the wiki... but it's
incomplete. (This based on the previous discussion regarding "native
capabilities", alternative to xmlforamt and stuff like that ..)

-

Separate static and dynamic parts of plugin/member configuration
http://www.opensync.org/ticket/1013

I'm not quite sure if we still can do this without touching any API. If so
this is not blocking 0.39.

.......

That's all. I hope there is no further need for tickets in 0.39. All tickets
not related to API changes will get moved to 0.40. If you have any thing left
which needs to be fixed in 0.39 - please drop me a mail.

Best Regards,
Daniel

------------------------------------------------------------------------------
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Daniel Gollub-2]

On Sunday 29 March 2009 06:28:04 pm Daniel Gollub wrote:
[...]
> For those who don't hesitate to contribute to /trunk - please assign a
> ticket to yourself from this query:
> http://www.opensync.org/query?status=assigned&status=new&status=reopened&gr
>oup=status&milestone=OpenSync+0.39

API breaking is nearly over. I already ported some plugins which i was able to
build. Some plugins i hoped to since outstanding porting patches getting
committed to SVN. Will provide new full-porting patch for those plugins which
don't have updated yet when the other tickets got addressed.

Short status updates on the API tickets:

>
>
> Currently on our API breaking list:
>
> [API] OSyncObjTypeSinkFunctions struct from public API/headers
> http://www.opensync.org/ticket/1086

done.

>
> -
>
> [API] Drop osync_objtype_set_slowsync() and add parameter osync_bool
> *slowsync to plugin connect()
> http://www.opensync.org/ticket/1085

done.

>
> -
>
> [API] Common API interface pattern for list-implementations
> http://www.opensync.org/ticket/975
>
> Björn is working on that.

still ongoing - expected to be complete soon.

>
> -
>
> [API] size_t/unsigned int review and cleanup
> http://www.opensync.org/ticket/974

done for the public API - so not blocking anymore 0.39 milestone. Got moved to
0.40

>
> -
>
> Make OSyncCapabilities and the use of Merger/Demerge format independent
> http://www.opensync.org/ticket/1084
>
> Still need to finish my "design" draft. As soon this is ready i'll drop a
> new mail about this. I already started to make some notes in the wiki...
> but it's incomplete. (This based on the previous discussion regarding
> "native capabilities", alternative to xmlforamt and stuff like that ..)

This is still open ... i plan to invest today my time on that.

>
> -
>
> Separate static and dynamic parts of plugin/member configuration
> http://www.opensync.org/ticket/1013
>
> I'm not quite sure if we still can do this without touching any API. If so
> this is not blocking 0.39.

Still need to be clarified if this involves any API change. if not this is not
blocking 0.39

Best regards,
Daniel

------------------------------------------------------------------------------
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Chris Frey-2]

On Sun, Mar 29, 2009 at 06:28:04PM +0200, Daniel Gollub wrote:
> The python wrapper is currently not building due to all this changes.
> The wrapper doesn't have high priority as stabilizing the (C) API.
> (It's up for takers if someone wants to port the wrapper ... otherwise
> i'll do that right before tagging 0.39).

I took a stab at this and committed it to SVN.  Should compile cleanly
now for everyone.

- Chris


------------------------------------------------------------------------------
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Daniel Gollub-2]

On Wednesday 01 April 2009 12:21:24 am Chris Frey wrote:
> On Sun, Mar 29, 2009 at 06:28:04PM +0200, Daniel Gollub wrote:
> > The python wrapper is currently not building due to all this changes.
> > The wrapper doesn't have high priority as stabilizing the (C) API.
> > (It's up for takers if someone wants to port the wrapper ... otherwise
> > i'll do that right before tagging 0.39).
>
> I took a stab at this and committed it to SVN.  Should compile cleanly
> now for everyone.


Builds perfectly fine on my box!
Awesome - Thanks a lot!

Best Regards,
Daniel

------------------------------------------------------------------------------
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Bjšoern Ricks-2]

Hi

here is a short status update for all people who are waiting for the
next release ;-)

> On Sunday 29 March 2009 06:28:04 pm Daniel Gollub wrote:
> [...]
>  
>> For those who don't hesitate to contribute to /trunk - please assign a
>> ticket to yourself from this query:
>> http://www.opensync.org/query?status=assigned&status=new&status=reopened&gr
>> oup=status&milestone=OpenSync+0.39
>>    
>
> API breaking is nearly over. I already ported some plugins which i was able to
> build. Some plugins i hoped to since outstanding porting patches getting
> committed to SVN. Will provide new full-porting patch for those plugins which
> don't have updated yet when the other tickets got addressed.
>
> Short status updates on the API tickets:
>
>  
>> Currently on our API breaking list:
>>
>> [API] OSyncObjTypeSinkFunctions struct from public API/headers
>> http://www.opensync.org/ticket/1086
>>    
>
> done.
>  

Yesterday we had to break this api again after spotting a big issue with
our IPC implementation. Therefore Michael Bell removed the batch_commit
callback function completely from the api. This isn't a shortcoming for
most plugins because the only plugins which used that function were
syncml and python.

>  
>> -
>>
>> [API] Drop osync_objtype_set_slowsync() and add parameter osync_bool
>> *slowsync to plugin connect()
>> http://www.opensync.org/ticket/1085
>>    
>
> done.
>
>  
>> -
>>
>> [API] Common API interface pattern for list-implementations
>> http://www.opensync.org/ticket/975
>>
>> Björn is working on that.
>>    
>
> still ongoing - expected to be complete soon.
>  

Done and committed in r5448. Now all list related interface will return
a OSyncList. The returned OSyncList is always a shallow copy of an
internal opensync structure/list and has to be freed in the application
or plugin. Please be sure that osync_list_free is called on the returned
list to avoid memory leaks.

>> -
>>
>> [API] size_t/unsigned int review and cleanup
>> http://www.opensync.org/ticket/974
>>    
>
> done for the public API - so not blocking anymore 0.39 milestone. Got moved to
> 0.40
>
>  

Internal api still needs cleanup but it isn't blocking the next release.
This should be a trivial task too.

>> -
>>
>> Make OSyncCapabilities and the use of Merger/Demerge format independent
>> http://www.opensync.org/ticket/1084
>>
>> Still need to finish my "design" draft. As soon this is ready i'll drop a
>> new mail about this. I already started to make some notes in the wiki...
>> but it's incomplete. (This based on the previous discussion regarding
>> "native capabilities", alternative to xmlforamt and stuff like that ..)
>>    
>
> This is still open ... i plan to invest today my time on that.
>
>  

The discussion is still ongoing. Daniel could you write a short mail
about the current status and your planning?

>> -
>>
>> Separate static and dynamic parts of plugin/member configuration
>> http://www.opensync.org/ticket/1013
>>
>> I'm not quite sure if we still can do this without touching any API. If so
>> this is not blocking 0.39.
>>    
>
> Still need to be clarified if this involves any API change. if not this is not
> blocking 0.39
>
>
>  

I am not sure about this ticket and the current status. It was
originally created by Henrik. So Henrik could you write some sentences
about it?

--
/Bjoern Ricks

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Daniel Gollub-3]

On Thursday 09 April 2009 09:30:16 am Bjoern Ricks wrote:
> Hi
>
> here is a short status update for all people who are waiting for the
> next release ;-)

Great - thanks for keeping everyone up to date!

[...]

> >>
> >> [API] Common API interface pattern for list-implementations
> >> http://www.opensync.org/ticket/975
> >>
> >> Björn is working on that.
> >
> > still ongoing - expected to be complete soon.
>
> Done and committed in r5448. Now all list related interface will return
> a OSyncList. The returned OSyncList is always a shallow copy of an
> internal opensync structure/list and has to be freed in the application
> or plugin. Please be sure that osync_list_free is called on the returned
> list to avoid memory leaks.

Björn, thanks for completing this!

>
> >> -
> >>
> >> [API] size_t/unsigned int review and cleanup
> >> http://www.opensync.org/ticket/974
> >
> > done for the public API - so not blocking anymore 0.39 milestone. Got
> > moved to 0.40
>
> Internal api still needs cleanup but it isn't blocking the next release.
> This should be a trivial task too.

Right.

>
> >> -
> >>
> >> Make OSyncCapabilities and the use of Merger/Demerge format independent
> >> http://www.opensync.org/ticket/1084
> >>
> >> Still need to finish my "design" draft. As soon this is ready i'll drop
> >> a new mail about this. I already started to make some notes in the
> >> wiki... but it's incomplete. (This based on the previous discussion
> >> regarding "native capabilities", alternative to xmlforamt and stuff like
> >> that ..)
> >
> > This is still open ... i plan to invest today my time on that.
>
> The discussion is still ongoing. Daniel could you write a short mail
> about the current status and your planning?

Still waiting for some comments on [RFC] Plugin specifc capabilities II

http://thread.gmane.org/gmane.comp.misc.opensync.devel/3787/focus=3818

Patrick, any chance to review/read/think about this mail?

>
> >> -
> >>
> >> Separate static and dynamic parts of plugin/member configuration
> >> http://www.opensync.org/ticket/1013
> >>
> >> I'm not quite sure if we still can do this without touching any API. If
> >> so this is not blocking 0.39.
> >
> > Still need to be clarified if this involves any API change. if not this
> > is not blocking 0.39
>
> I am not sure about this ticket and the current status. It was
> originally created by Henrik. So Henrik could you write some sentences
> about it?

Actually i planned to take care about this once the capabilities issue is
fixed. IIRC Henrik is quite busy with other thing and doesn't have time right
now taking care about this. Maybe we should open this for other takers?

Btw. there are two missing from the 0.39 Roadmap:

[API] Check public interfaces for proper error reporting
http://opensync.org/ticket/1087

Björn, maybe something for you since you're our most talented API-Maintainer!
;)

[TRIVIAL][testsuite] tests/sync-tests/check_multisync.c unported/disabled
http://opensync.org/ticket/981

Ian started on this - but is unavailable to continue working on this. I highly
recommend to work on testcases like this to learn a lot from OpenSync
Internals and Engine - to become a OpenSync Guru ;)

Best Regards,
Daniel

--
Daniel Gollub                        Geschaeftsfuehrer: Ralph Dehner
FOSS Developer                       Unternehmenssitz:  Vohburg
B1 Systems GmbH                      Amtsgericht:       Ingolstadt
Mobil: [phone]         Handelsregister:   HRB 3537
EMail: gollub@...          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


------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Patrick Ohly]

On Thu, 2009-04-09 at 09:49 +0200, Daniel Gollub wrote:

> On Thursday 09 April 2009 09:30:16 am Bjoern Ricks wrote:
> > >> Make OSyncCapabilities and the use of Merger/Demerge format independent
> > >> http://www.opensync.org/ticket/1084
> > >>
> > >> Still need to finish my "design" draft. As soon this is ready i'll drop
> > >> a new mail about this. I already started to make some notes in the
> > >> wiki... but it's incomplete. (This based on the previous discussion
> > >> regarding "native capabilities", alternative to xmlforamt and stuff like
> > >> that ..)
> > >
> > > This is still open ... i plan to invest today my time on that.
> >
> > The discussion is still ongoing. Daniel could you write a short mail
> > about the current status and your planning?
>
> Still waiting for some comments on [RFC] Plugin specifc capabilities II
>
> http://thread.gmane.org/gmane.comp.misc.opensync.devel/3787/focus=3818
>
> Patrick, any chance to review/read/think about this mail?

I have read it, but didn't have specific comments. I suppose conversion
could be implemented in several ways and you'll find out how well the
design works when actually implementing it in several plugins.

--
Bye, Patrick Ohly
--  
Patrick.Ohly@...
http://www.estamos.de/



------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Henrik /KaarPoSoft]

Daniel Gollub wrote:
>
> Still waiting for some comments on [RFC] Plugin specifc capabilities II
>
> http://thread.gmane.org/gmane.comp.misc.opensync.devel/3787/focus=3818
>
>  
Please also see http://thread.gmane.org/gmane.comp.misc.opensync.devel/3819

>>>> Separate static and dynamic parts of plugin/member configuration
>>>> http://www.opensync.org/ticket/1013
>>>>
>>>> I'm not quite sure if we still can do this without touching any API. If
>>>> so this is not blocking 0.39.
>>>>        
>>> Still need to be clarified if this involves any API change. if not this
>>> is not blocking 0.39
>>>      
>> I am not sure about this ticket and the current status. It was
>> originally created by Henrik. So Henrik could you write some sentences
>> about it?
>>    
>
> Actually i planned to take care about this once the capabilities issue is
> fixed. IIRC Henrik is quite busy with other thing and doesn't have time right
> now taking care about this. Maybe we should open this for other takers?
>
>  

I know very little of the internals of OpenSync, and I fear that I will
probably introduce more problems than solutions if I start playing with
this.
I have only limited time, and I think it is best spend on mozilla-sync
and the interface to OpenSync and SyncML

/Henrik


------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Chris Frey-2]

On Thu, Apr 09, 2009 at 09:30:16AM +0200, Bjoern Ricks wrote:

> >> [API] Common API interface pattern for list-implementations
> >> http://www.opensync.org/ticket/975
> >>
> >> Bj?rn is working on that.
> >>    
> >
> > still ongoing - expected to be complete soon.
> >  
> Done and committed in r5448. Now all list related interface will return
> a OSyncList. The returned OSyncList is always a shallow copy of an
> internal opensync structure/list and has to be freed in the application
> or plugin. Please be sure that osync_list_free is called on the returned
> list to avoid memory leaks.

I'm assuming that not all functions that return a OSyncList* behave
this way?  For example, osync_plugin_resource_get_objformat_sinks().

(This could very well be my API ignorance showing) :-)

- Chris


------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Bjšoern Ricks-2]

Chris Frey schrieb:

> On Thu, Apr 09, 2009 at 09:30:16AM +0200, Bjoern Ricks wrote:
>  
>>>> [API] Common API interface pattern for list-implementations
>>>> http://www.opensync.org/ticket/975
>>>>
>>>> Bj?rn is working on that.
>>>>    
>>>>        
>>> still ongoing - expected to be complete soon.
>>>  
>>>      
>> Done and committed in r5448. Now all list related interface will return
>> a OSyncList. The returned OSyncList is always a shallow copy of an
>> internal opensync structure/list and has to be freed in the application
>> or plugin. Please be sure that osync_list_free is called on the returned
>> list to avoid memory leaks.
>>    
>
> I'm assuming that not all functions that return a OSyncList* behave
> this way?  For example, osync_plugin_resource_get_objformat_sinks().
>
> (This could very well be my API ignorance showing) :-)
>
> - Chris
>
>  

Thanks for giving me this hint. I completely forgot to check existing
functions which already returned an OSyncList. Today I changed
(hopefully) all list functions to return a copy of the internal list.

Bjoern

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel