|
From: Chris F. <cd...@fo...> - 2011-07-18 21:40:55
|
Hi, I've made a number of changes and fixed some memory leaks in the capabilities API. You can see the last change here: http://repo.or.cz/w/opensync/opensync-cdf.git/commitdiff/a826a3ce69bd1e84beca7344c18e2a0047306960 I've updated the evolution2, vformat, and xmlformat plugins as well, with the small API change required, since I'm tracking them. For plugin authors, the change is pretty simple: Change: osync_capability_new() To: osync_capabilities_add_new_capability() and Change: osync_capabilities_objtype_new() To: osync_capabilieis_add_new_objtype() The reason for this change was because the capabilities API behaved differently than the rest of opensync. The _new() calls would add the new object to an internal list, and return an unref'd pointer. This is inconsistent with what the user will expect from every other _new() call in the library. Also, due to this oddity, some of the internal implementations were very difficult to get right. While building the capabiities hierarchy, there could be errors after an object was created, but before it could be returned successfully. I have changed the internal API so that all calls to _new(), _ref(), and _unref(), in the capabilities API behave as expected. I have also hidden a number of calls, in favour of promoting just the top level OSyncCapabilities objects. This is all that the user should need to worry about, when it comes to memory management, and the normal _new(), _ref(), and _unref() calls are available for it only. API Changes: ============ Removed (moved to internal) osync_capabilities_objtype_new osync_capabilities_objtype_ref osync_capabilities_objtype_unref osync_capability_new osync_capability_ref osync_capability_unref Added osync_capabilities_add_new_objtype osync_capabilities_add_new_capability Background: =========== For those who don't know what the "capabilities hierarchy" is, here's the docs that I added to opensync_capabilities_private.h. /** * @brief Represent a Capabilities object * * This is the top level Capabilities object, which contains a list of * lists of capability objects for each objtype. * * For example, if your device has a set of capabilities, you could call the * set "foodevice-caps". This would be the Capabilities format name. * This format name could contain different capability lists for each * objtype supported, for example "contact" or "event" or both. * * The names of the capabilities do not have to match anything else, but * if they do not match something opensync knows about, it will need a * caps-converter (capabilities converter) to translate your list of * capability objects for, say, "contact" into something it knows, say, * "xmlformat-contact". * * foodevice-caps * contact * name * address1 * phonenumber * event * date * location * * I don't know if multiple objtypes are ever useful, but they are possible, * given the 3 structures: OSyncCapabilities, OSyncCapabilitiesObjType, * and finally OSyncCapability. * * Note that OSyncCapability is a hierarchical list, having its own children. * It also has a list of OSyncCapabilityParameter objects. * */ The Capabilities API could use some feedback and thought. Currently there is no way to properly manage the OSyncCapabilityParameters programmatically. Enjoy, - Chris |
|
From: deloptes <del...@ya...> - 2011-08-07 13:52:27
|
Could you by chance, please, have a look at this. I just tried to recompile everything into a clean directory, but I can not list some of the plugins. I don't have much time .... is it working for you? I'll test it in the next days on debian testing. I'm testing it now on debian squeeze with trinity thanks and regards emanoil@maistor:/opt/software/opensync_svn/libopensync-plugin-syncml/trunk/build$ ls /opt/custom/opensync/lib/libopensync1/plugins/ evo2-sync.so file-sync.so kdepim-sync.so syncml-plugin.so emanoil@maistor:/opt/software/opensync_svn/libopensync-plugin-syncml/trunk/build$ osynctool --listplugins Available plugins: file-sync kdepim-sync |
|
From: Chris F. <cd...@fo...> - 2011-08-08 20:24:15
|
Hi, I ran a quick test, and here's the result: [cdfrey bin]$ pwd /home/cdfrey/software/opensync/git/rootdir/bin [cdfrey bin]$ ls ../lib/libopensync1/plugins/ akonadi-sync.so evo2-sync.so file-sync.so gcalendar.so [cdfrey bin]$ ./osynctool --listplugins Available plugins: google-data evo2-sync file-sync akonadi-sync On Sun, Aug 07, 2011 at 03:52:00PM +0200, deloptes wrote: > Could you by chance, please, have a look at this. I just tried to recompile > everything into a clean directory, but I can not list some of the plugins. > I don't have much time .... is it working for you? > I'll test it in the next days on debian testing. I'm testing it now on > debian squeeze with trinity > > thanks and regards > > emanoil@maistor:/opt/software/opensync_svn/libopensync-plugin-syncml/trunk/build$ > ls /opt/custom/opensync/lib/libopensync1/plugins/ > evo2-sync.so file-sync.so kdepim-sync.so syncml-plugin.so > emanoil@maistor:/opt/software/opensync_svn/libopensync-plugin-syncml/trunk/build$ > osynctool --listplugins > Available plugins: > file-sync > kdepim-sync > > > > ------------------------------------------------------------------------------ > BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA > The must-attend event for mobile developers. Connect with experts. > Get tools for creating Super Apps. See the latest technologies. > Sessions, hands-on labs, demos & much more. Register early & save! > http://p.sf.net/sfu/rim-blackberry-1 > _______________________________________________ > Opensync-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensync-devel |
|
From: deloptes <del...@ya...> - 2011-08-14 14:29:25
|
Chris Frey wrote: > Hi, > > I ran a quick test, and here's the result: > > [cdfrey bin]$ pwd > /home/cdfrey/software/opensync/git/rootdir/bin > > [cdfrey bin]$ ls ../lib/libopensync1/plugins/ > akonadi-sync.so evo2-sync.so file-sync.so gcalendar.so > > [cdfrey bin]$ ./osynctool --listplugins > Available plugins: > google-data > evo2-sync > file-sync > akonadi-sync > I compiled with debug options and tested in the testing env. This seems to be the problem ;-) We need to fix syncml - regards. I'm pretty busy recently and can not do anything about. $ osynctool --listplugins ERROR: Unable to open module /opt/testing/opensync/lib/libopensync1/plugins/syncml-plugin.so: /opt/testing/opensync/lib/libopensync1/plugins/syncml-plugin.so: undefined symbol: osync_capabilities_objtype_new EXIT_ERROR: osync_module_load: Unable to open module /opt/testing/opensync/lib/libopensync1/plugins/syncml-plugin.so: /opt/testing/opensync/lib/libopensync1/plugins/syncml-plugin.so: undefined symbol: osync_capabilities_objtype_new Available plugins: file-sync akonadi-sync |
|
From: deloptes <del...@ya...> - 2011-08-14 14:35:24
|
And another one. Not that I'm using it but it was about testing
$ osynctool --listformats
ERROR: Unable to open
module /opt/testing/opensync/lib/libopensync1/formats/vformat-xmlformat.so: /opt/testing/opensync/lib/libopensync1/formats/vformat-xmlformat.so:
undefined symbol: osync_capability_new
EXIT_ERROR: osync_module_load: Unable to open
module /opt/testing/opensync/lib/libopensync1/formats/vformat-xmlformat.so: /opt/testing/opensync/lib/libopensync1/formats/vformat-xmlformat.so:
undefined symbol: osync_capability_new
ERROR: Unable to find xslt-contact format
EXIT_ERROR: osync_module_get_conversion_info: Unable to find xslt-contact
format
Format: file
Object Type: data
Format: plain
Object Type: data
Format: memo
Object Type: note
Format: xslt
Object Type: contact
Format: vcard21
Object Type: contact
Format: vcard30
Object Type: contact
Format: vevent10
Object Type: event
Format: vevent20
Object Type: event
Format: vtodo10
Object Type: todo
Format: vtodo20
Object Type: todo
Format: vjournal
Object Type: note
Format: vnote11
Object Type: note
|
|
From: deloptes <del...@ya...> - 2011-11-06 01:49:55
|
Chris Frey wrote: > Hi, > > I ran a quick test, and here's the result: > > [cdfrey bin]$ pwd > /home/cdfrey/software/opensync/git/rootdir/bin > > [cdfrey bin]$ ls ../lib/libopensync1/plugins/ > akonadi-sync.so evo2-sync.so file-sync.so gcalendar.so > > [cdfrey bin]$ ./osynctool --listplugins > Available plugins: > google-data > evo2-sync > file-sync > akonadi-sync > > > > On Sun, Aug 07, 2011 at 03:52:00PM +0200, deloptes wrote: >> Could you by chance, please, have a look at this. I just tried to >> recompile everything into a clean directory, but I can not list some of >> the plugins. I don't have much time .... is it working for you? >> I'll test it in the next days on debian testing. I'm testing it now on >> debian squeeze with trinity >> >> thanks and regards >> >> emanoil@maistor:/opt/software/opensync_svn/libopensync-plugin-syncml/trunk/build$ >> ls /opt/custom/opensync/lib/libopensync1/plugins/ >> evo2-sync.so file-sync.so kdepim-sync.so syncml-plugin.so >> emanoil@maistor:/opt/software/opensync_svn/libopensync-plugin-syncml/trunk/build$ >> osynctool --listplugins >> Available plugins: >> file-sync >> kdepim-sync >> >> Hi, I removed the whole install dir on my test server and rebuild basics from scratch. I can't recall what was said exactly about transition of plugins from svn to git and the new functionality. However what is in svn seems not to have the new function names. I updated akonadi-sync, file, vformat, xmlformat etc. It compiles and it probably works, so what do we do with those repos and which one is to be used ? Before breaking something I would like to ask first. regards |