meetings/irc: opensync-20090108.log

10:02 -!- dgollub changed the topic of #opensync to: OpenSync project IRC Meeting | No support question during this time please! No bug fixing :)
10:03 < dgollub> bricks: do you want to be the moderator? or do you just want to take the minuts?
10:05 < bricks> dgollub: whatever ;)
10:05 < dgollub> cool .. go ahead ;)
10:05  * dgollub present
10:05  * bricks present
10:05 < bricks> anybody else?
10:06 < dgollub> afaik bellmich is unavailable due to a meeting which came along...
10:06 < bricks> doesn't seems so
10:06 < dgollub> ok .. great then i guess this goes really quick ;)
10:06 < bricks> maybe :)
10:06 < bricks> Action Items from previous Meetings:
10:07 < dgollub> AI bricks, dgollub: introduce merger/demerge format-plugin functions - make merging independent of xmlformat <- complete .. i would say
10:07 < bricks> me too
10:07 < bricks> * AI dgollub: introduce example-plugin using static-capabilities
10:07 < bricks> * AI dgollub: document each plugin function - which bits of  information can be set/reported at each point - entry point documentation
10:07 < bricks> * AI dgollub: doing engine hacking alread, do documentation  once hacking is done
10:08 < bricks> * AI ChrisH: offload bricks by moving doxygen annotation of  "version" and "plugin" modules to header file (no function renaming!)
10:08 < bricks> * AI bricks, dgollub: introduce merger/demerge format-plugin  functions - make merging independent of xmlformat
10:08 < bricks> * AI kaarposoft tries to look into splitting static plugin  information out of the members plugin configuration.
10:08 < dgollub> none of my others are done yet .. keep them on the list. i'll do them ASAP. i hope the next days there is less on my bug-list ....
10:08 < bricks> dgollub: much work for you ;)
10:08 < dgollub> i'm still working towards the mixed-objtype thing.. (but this require some refactoring/cleanup in the engine before breaking things again)
10:09 < bricks> ok fine with me
10:09 < dgollub> reg. kaarposoft AI's ...
10:09 < bricks> dgollub: did you see http://www.opensync.org/ticket/1022
10:09 < dgollub> ... he did some write up. Not  quite sure  if he already started implenetating this
10:09 < dgollub> yeah
10:10 < bricks> i started with documenting the functions already
10:10 < dgollub> cool
10:10 < bricks> but i need some info for discovery
10:10 < dgollub> bricks: could you assign the ticket to yourself?
10:10 < bricks> maybe you are able to add the details later
10:10 -!- sunilmohan [n=Sunil@124.123.203.199] has joined #opensync
10:10 < bricks> of course
10:10 < dgollub> ok .. let's do the details later
10:10 < bricks> so we finished #1
10:10 < dgollub> bricks: maybe to not miss each other.. ask on opensync-devel@ .. their is more auideance
10:10 < bricks> next
10:11 < dgollub> but for "quick" question feel free to ask in IRC
10:11 < dgollub> ok . .next top.
10:11 < bricks> which question?
10:11 < dgollub> the discovery function questions
10:11 < bricks> i get it
10:11 < bricks> next
10:11 < bricks> 2. User vs. Developer documentation (from last meeting)
10:12 < dgollub> Tuju: around?
10:12 < bricks> no then we should skip that task again
10:12 < dgollub> kk
10:13 < bricks> 3. Further API breakage before 0.40
10:13 < bricks> the interesting item ;9
10:13 < dgollub> hehe
10:13 < bricks> * Database interface
10:14 < bricks> i would like to have an interface for different db access before 0.40
10:14 < dgollub> you add this one.. which database interface are you talking about? the OSyncDB one? or all interface related to the database ting?
10:14 < bricks> because if we add a interface after 0.40 we have to break the api again
10:14 < bricks> store all data in a different dbs
10:15 < bricks> possibility to change db during runtime
10:15 < dgollub> yeah .. my plan for this is .. to unexport OSyncDB from public API
10:15 < bricks> we need this for a server mode
10:15 < dgollub> and drop the 'file-path' parameter from OSyncHahstable
10:15 < bricks> but a apllication should be able to choose a db
10:15 < dgollub> sure?
10:16 < dgollub> ok .. but we still can add this interface to select/configure a database 
10:16 < bricks> yes. how can a server change the db instead?
10:16 < dgollub> as long we only have sqlite3 we just remove every interface which might change in future from public API
10:17 < bricks> we need and interface to pass a db to the engien (in my opinion)
10:17 < dgollub> since we don't have any other DB implementation in the background i would avoid to provide with 0.40 an interface for this.. we still can add new interfaces withotu breaking the API
10:17 < dgollub> yes. but do we need this already for 0.40? we can also have this with 0.41 .. withou breaking the API
10:17 < bricks> ok maybe it's possible to add only apis
10:18 < bricks> and not to breake anything
10:18 < bricks> ok fine. db api after 0.40
10:18 < dgollub> i would not implement interface we can't real use today.. due to lack of different databsae implementations.. and for 0.40-timeframe thats too much
10:19 < bricks> * Hashtable interface
10:19 < dgollub> ok ... so but we still need to do following things to be safe to get this transparent-database thing done:
10:19 < dgollub> - drop OSyncDB from public API
10:19 < bricks> yes we should drop it
10:19 < dgollub> - fix any interface which uses a file-path to access a sqlite3 db
10:20 < dgollub> the only reason why i haven't dropped it yet is syncml plugin
10:20 < bricks> afterwards (>0.40) we can add a api to select a db
10:20 < dgollub> it's using OSyncDB .. to store just everything from the SyncML DeviceInformatin
10:21 < bricks> so we need a api to store plugin data?
10:22 < dgollub> yes in certain circumstances ... not quite sure if we should "abuse" AdvancedOptions interface to store stuff like .. if runs in UTC or supports "number of changes"
10:23 < dgollub> maybe we should keep a tiny set of OSyncDB
10:23 < bricks> dgollub: and annotate it as deprecated
10:23 < dgollub> whcih doesn't allow to create random-databases .. just provides access to one single database
10:24 < bricks> fine
10:24 < dgollub> but yeah .. then is this story with SQL-queries ..a nd compability 
10:24 < dgollub> different databases in the background could mean different quries break
10:25 < bricks> therefore we need some db layers
10:25 < bricks> ;)
10:25 < bricks> after 0.40
10:25 < dgollub> what about a key=value store?
10:25 < bricks> i thought about that too just a sec ago ;)
10:25 < dgollub> something like the anchor .. which isn't restricted to a objtype
10:26 < dgollub> the anchor table changed that only one entry per objtype is allowed
10:26 < dgollub> for syncml we would need to store several values for the main-sink
10:26 < bricks> if syncml hasn't to complex data it's ok
10:26 < dgollub> now .. actually it's only 3 different fields IIRC .. or maybe 5
10:26 < dgollub> bricks: do you have a syncml group?
10:27 < bricks> nope
10:27 < dgollub> ok .. just a sec
10:28 < dgollub> http://cryptomilch.de/~dgollub/syncmldb.txt
10:29 < dgollub> this is also storing the SyncML capabilities.. we don't need this actually .. we could also store this and reassemble this with OSyncCapabilities stored data
10:29 < dgollub> so all the property tables can be ignored
10:30 < dgollub> content_type_capabilities is also information which is stored in the OSyncPluginResource
10:30 < dgollub> utc BOOLEAN, large_objects BOOLEAN, number_of_changes BOOLEAN
10:30 < dgollub> those are SyncML specifc and needs to get stored
10:32 < dgollub> so i guess the key=value thing would be enough
10:32 < bricks> ok then we shrink the osyncdb to key=value pairs in one databse and table
10:32 < dgollub> yeah .. and the "database" is a fixed one.. and can't be a random-file like it is today
10:32 < bricks> yes it should be. also easier to debug
10:33 < dgollub> right now SyncML plugin created one with osync_db_new(osync_plugin_get_config_dir(plugin)"/syncml.db", error)
10:33 < dgollub> and required to switch to any other DB at some later point
10:33 < dgollub> ok .. so let's summaries:
10:33 < bricks> would you like to send a proposal to devel?
10:33 < dgollub> yeah i'll do that
10:33 < bricks> thanks
10:33 < dgollub> OSyncDB interface got completey removed from public API
10:34 < bricks> ai dgollob: create proposal for new OSyncDB interface
10:34 < dgollub> A new or shrinked interface will replace it with a "key=value" interface which is ObjTypeSink independent
10:34 < dgollub> which can be used to store persitent data for a peer and retrieved only by the plugin which stored it
10:35 < dgollub> Hashtable interface
10:35 < dgollub> * no file-path parameter 
10:35 < dgollub> thats related
10:35 < dgollub> IIRC the hashtable could be also have a random-file-path to a sqlite3 database file
10:35 < dgollub> i also want remove the parameter here
10:35 < dgollub> so we have control about the database in the background
10:35 < bricks> fine. we should really do this
10:36 < bricks> only a small interface for all db access
10:36 < dgollub> which brings me to the next thing:
10:36 < dgollub> Drop of osync_plugin_get_config_path()
10:36 < bricks> easier to handle
10:36 < bricks> which data is stored in this path?
10:36 < dgollub> We should really drop this interface from public API ... to avoid that any application or interface starts dumping data to this directory
10:37 < bricks> the xml option file?
10:37 < dgollub>   ~/.opensync/group1/2/ <- it's this path .. or what every your group/member configratuion is  it
10:37 < dgollub> no .. it'S the directory
10:37 < bricks> which data is stored in this path?
10:37 < bricks> the config i guess :)
10:37 < dgollub> lot's of plugins were using this to create custom file to dump database files.. e.g. the
10:37 < dgollub> dgollub@marvin:~/.opensync/group1/2> ls
10:37 < dgollub> anchor.db  file-sync.conf  hashtable-contact.db  hashtable.db  syncmember.conf
10:38 < dgollub> perfect bad example
10:38 < dgollub> two random hashtable database sqlite3 files.. completly unwanted 
10:38 < dgollub> the plugin created hashtable-contact.db
10:38 < dgollub> it's not in control of the framework
10:39 < dgollub> dgollub@marvin:~/.opensync/group2/1> ls
10:39 < dgollub> anchor.db  devinf.db  syncmember.conf  syncml-obex-client.conf
10:39 < dgollub> devinf.db is the syncmldb.txt dump i sent you
10:39 < bricks> drop that interface
10:39 < dgollub> also not in control of the framework due to OSyncDB and osync_plugin_get_config_path
10:39 < dgollub> yea...
10:39 < dgollub> Multiply-Summary Callback
10:39 < dgollub> * drop OSyncSinkEngine? * get MappingEntryEngines? per Member? 
10:39 < bricks> the plugin should not be aware of paths
10:40 < dgollub> yeah - exactly.
10:40 < dgollub> henrik came up with this... multiply-summary callback thing
10:40 < bricks> i don't know what that is for at all
10:40 < dgollub> he asked to get more comfortable interfaces to assemble a multiply summary
10:41 < dgollub> bricks: did you see the "synchronization forecast" in osynctool?
10:41 < bricks> yes but i don't know what it is too
10:41 < dgollub> ok ... ;)
10:42 < dgollub> The idea is to summaries what the engine thinks to write to the devices ..after multiplying
10:42 < bricks> and multipying is?
10:42 < dgollub> so .. the user has the chance to review before writing to the devices
10:42 < bricks> a thats for an old ticket i guess
10:42 < dgollub> multiplying is the logic of the engine which needs to decide which changes needs to get committed to .. and how (i.e. which changetype modified/added/deleted)
10:43 < bricks> thanks i get it
10:43 < dgollub> yes - and it's also for debugging developing crazy multiply features
10:43 < dgollub> thats really  tought logic ... since there are some protocols which don't know the changetype "ADDED" .. they always report with "MODIFIED" .. even if the entry is completely new
10:44 < bricks> this interface can change the handling of entries
10:44 < dgollub> but we need to commit this fake-"MODIFIED" changes into "ADDED" to serve the different peers .. otherwise they would reject the new record
10:44 < bricks> ?
10:44 < dgollub> no .. it's just to summaries what is going to be written to the peers
10:45 < dgollub> in case there is a duplicate mess .. you would see this that 1000 new entries gets added on each peer
10:45 < bricks> ok
10:46 < dgollub> or .. if 1000 entries get deleted ;)
10:46 < dgollub> right now you have to accept in osynctool everytime this summary before continuning syncing... the appliaction can also (safely) abort the sync if the user rejcets
10:47 < dgollub> it would call immeditally disconnect() functions of the peers
10:47 < dgollub> so it would  abort kind of cleanly
10:47 < bricks> ok
10:47 < dgollub> and all this is implemented in a engien callback function
10:48 < dgollub> the callback is called multiply_summary or something like that .. and an example implemenation looks like this:
10:48 < bricks> nice feature
10:48 < dgollub> http://opensync.org/browser/osynctool/trunk/tools/osynctool.c#L253
10:49 < bricks> i'll take a deep look at the code later.
10:49 < bricks> it's a really nice feature
10:49 < bricks> i remember a ticket related to this
10:49 < dgollub> this multiply interface can access via  the OSyncEngine all OSyncObjEngine ... and can get per OSyncObjEngine the "MappingEntryEngine" which is basically the object which contains the information for each entry and each peer  which would get written
10:49 < dgollub> yeah ..this ticket got fixed  (at least if we're talking about the same ticket)
10:50 < dgollub> The problem henrik found is .. when iterrting over OSyncObjEngine and then over OSyncSinkEngine (which also store a OSyncMember pointer) the order of the members is kind of random
10:51 < bricks> ahh i read a mail about this topic
10:52 < dgollub> for this summary i exported parts of OSyncSinkEngine... but i thinking right now about undoing this
10:52 < dgollub> and just came up with a interface like:
10:52 < dgollub> osync_obj_engine_{nth,num}_members()
10:53 < dgollub> and also give the OSyncMember a pointer to the list of OSyncMappingEntryEngine elements
10:53 < dgollub> so it's easier to write GUI widgets
10:53 < dgollub> and we get rid of the OSyncSinkEngine object again from the api
10:53 < dgollub> i really only introduce it to get acces to theOSyncMappingEntryEngiens per "member"
10:54 < dgollub> btw. if the current  osynctool implementation is not "user friendly" .. feel free to make it more understandble ;)
10:54 < dgollub> printf("\tMember %lli: Adding(%u) Modifying(%u) Deleting(%u)\n",
10:55 < dgollub> ok .. time is running - next topic?
10:55 < bricks> the new interface should be easier to understand
10:55 < bricks> ok next topic
10:55 < dgollub> bricks: do you ant to clean-up the osynctool implementation .. i really had the engine view on this ;)
10:55 < bricks> Define use of osync_assert() and osync_return{val,}_if_fail()           * osync_return_error{_val,}_if_fail() is required
10:56 < dgollub> i added this time ... 
10:56 < bricks> dgollub: i'll do this after creating more example apps
10:56 < bricks> could you create a ticket for this task?
10:56 < dgollub> we need to drop osync_assert() from the public interfaces which do parameter-list-valdation very soon .. since with a -DNDEBUG build this "protection" is gone
10:56 < dgollub> bricks: kk
10:56 < bricks> ai bricks: make osynctool more userfriednly
10:57 < dgollub> ai bricks: make osynctool synchroniation (multiply-)summary more intuitive 
10:57 < dgollub> not the entire beast ;)
10:57 < bricks> ok fine ;)
10:57 < dgollub> it's not worth it ;P
10:57 < dgollub> just that the testers and developers understand the summary thing
10:58 < dgollub> ok .. reg. osync_assert() .. we need to get rid of "parameter" proctectios with osync_assert() from the public interfaces
10:58 < dgollub> due to builds with -DNDEBUG
10:58 < dgollub> a NULL in the wrong  place by an applicaton should not honored with an assert() anyway ;P
10:59 < dgollub> instead i would  suggest to replace all with osync_return{val,}_if_fail()
10:59 < dgollub> expect the once which have an error parameter
10:59 < dgollub> -once 
10:59 < dgollub> +ones
11:00 < dgollub> for those we should not just return with FALSE or NULL .. we should also set an error
11:00 < dgollub> there is also an error type for this : OSYNC_ERROR_PROTOTYPE
11:00 < dgollub> or OSYNC_ERROR_PARAMETER .. not quit esure.. it was somethign with P i guess
11:00 < bricks> we talked about that and you are right. we have to remove assert
11:00 < dgollub> and to make this really simple.. introduce a macro which do this in one oline
11:00 < bricks> and introduce more errors
11:01 < dgollub> (yeah, just rolling this again for the meeting irc logs)
11:01 < dgollub> could you have a  look in introducing this macro?
11:01 < dgollub> i would say we keep this macro internal.. the others are also internal right now...
11:02 < bricks> but it's sometime necessary for plugins
11:02 < dgollub> something like osync_return_error{_val,}_if_fail(condition, [value ,] error)
11:02 < bricks> therefore i added osync_assert to public api some time ago
11:03 < dgollub> bricks: we still can set osync_assert() before some osync_return_if_fail() calls
11:03 < dgollub> so if it's build with -DNDEBUG it falls back to the osync_return_if_fail() .. if it's not build with -DNDEBUG .. it will assert()
11:03 < dgollub> btw. there is osync_assert_msg() .. i guess we could handle most common plugin bugs with that
11:04 < bricks> yes i know, but i would like to have all osync fail macros public
11:04 < dgollub> ah .. now i got what you mean
11:04 < dgollub> you want to have those to use them in the plugin.. not handle plugin bugs? ;)
11:04 < dgollub> aah .. ok actually there is no real reason to not ship those macros .. expect we have to keep them stable
11:04 < dgollub> bug i guess thats possible ;)
11:05 < dgollub> so feel free to move them to opensync.h
11:05 < bricks> thanks
11:05 < dgollub> do you take the  AI for osync_return_error{_val}_if_fail?
11:05 < bricks> ai bricks: make osync error/fail macros public
11:05 < dgollub> this would be two macros one which return void and which return whatever.
11:05 < bricks> i'll do that
11:06 < dgollub> cool
11:06 < dgollub> next topic?
11:06 < bricks> yes
11:06 < bricks> (two people and we run out of time :D)
11:06 < dgollub> hehe :P
11:06 < bricks> XMLFormat core-tree dropout Delay xmlformat-$pim scheam freeze? 
11:06 < bricks> simple answer: yes
11:06 < dgollub> ok ... cool
11:07 < dgollub> next?
11:07 < bricks> xmlformat isn't stable
11:07 < dgollub> yeah - completeyl agree
11:07 < bricks> so skip the freeze
11:07 < bricks> OpenSync 0.40 release without plugins? 
11:07 < bricks> i am not sure about releasing opensync without xmlformat and vformat?
11:07 < bricks> -?
11:07 < dgollub> this is related to the xmlformat-freeze .. i don't want to block opensync 0.40 due to missing xmlforamt.. sicne you still can use opensync without the xmlformat plugin
11:08 < dgollub> the idea is about not to release xmlforamt.. since the schema is not frozen
11:08 < dgollub> and not to  ship vformat with xmlformat converters... 
11:08 < bricks> ok
11:08 < dgollub> so the vformat plugin would only exist of the "format" functions.. no the "convertesr" once
11:08 -!- hrw [n=hrw@chello089078173235.chello.pl] has joined #opensync
11:08 < hrw> hi
11:08 < dgollub> this would allow that plugins still can register
11:09 < dgollub> ... those formats.
11:09 < bricks> but is opensync usable e.g. with kde-pim without these formats?
11:09 < dgollub> yes and no ;)
11:09 < hrw> bad luck ;( project meeting == no support questions.
11:09 < dgollub> without the complete vformat plugin it's unusable
11:09 < dgollub> hrw: (doesn't take long.. just few toopics left)
11:09 < bricks> ok. we should release 0.40 without them and afterwards get them stable really fast
11:09 < hrw> will ask later then about syncml-over-obex and calendar 
11:10 < dgollub> bricks: so .. if we just ship the vformat-plugin without converter...
11:10 < dgollub> the kdepim plugin still can register the format.. and gets something from the FormatEnv
11:10 < dgollub> so the kdepim still works
11:10 < bricks> ok fine
11:10 < dgollub> so you can sync with   kdepim <-> file-sync
11:10 < dgollub> since there is not conversion to the xmlforamt required
11:10 < bricks> i'll really would see 0.40 in a distribution ;)
11:10 < dgollub> what you can't do then: ... kdepim <-> syncml
11:11 < dgollub> i guess withotu the vformat xmlformat converters it's not ready for distro packaging at all ;)
11:11 < bricks> yeah i thought so too
11:11 < bricks> but kde can use it for development
11:11 < bricks> that would be cool too
11:12 < dgollub> so .. kdepim <-> syncml would work in theory...  but it's not recommended
11:12 < dgollub> due to missing merging/demerging .. sicne vformat doesn't do this by it's own
11:12 < bricks> i am fine with releasing opensync without the format converters
11:12 < dgollub> and it would also only work if kdepim would  have the some objformats as the syncml-peer - e.g. both using vcard21 .. (which is not hte case afaik)
11:12 < Tuju> hi
11:13 < dgollub> the the thing what i thing is quite important:
11:13 < bricks> first have a stable engine then have stable formats
11:13 < dgollub> what stil would work with 0.40 and relasing vformat plugin without conversters and realsing the syncml plugin:
11:13 < bricks> Tuju: hi
11:13 < dgollub> people still can sync file-sync <-> syncml .. safe!
11:13 < dgollub> and thats i guess today already meets user expection up  to 50% ;)
11:13 < bricks> we must announce that in the release
11:14 < Tuju> i think the key question here is, is the API in such state that it can be safely frozen?
11:14 < dgollub> yeah .. i plan to do big noise about that.. and try to provide some press contact .. so people the  news do announce stuff which gives wrong user expectiains
11:14 < dgollub> Tuju: which api are you talking about?
11:14 < Tuju> libopensync api.
11:15 < dgollub> Tuju: thats not the topic right now .. the opensync api is stable once we're done with 0.39
11:15 < Tuju> what api you're talking about?
11:15 < bricks> in my opinion we are on a good road to finalize the api
11:15 < Tuju> i thought you were talking about 0.40 and what will be released and what not. i think it's quite relevant.
11:15 < dgollub> i don't plan to touch after 0.39 the api .. at least not that hard we did in the entire 0.3x cycle
11:16 < dgollub> Tuju: yeah .. the topic is not reasling plugins
11:16 < dgollub> since poor plugins .. give poor expereince of the entire framework
11:16 < Tuju> which is quite much as what's going to happen in near future.
11:16 < dgollub> if the vformat plugin's converter cause duplicate/dataloss ... the regular user would things it's the fault of "OpenSync" .. and not of the vformat-converter
11:17 < Tuju> don't forget that there will be 0.5 and 0.6 someday, it doesn't have to be perfect.
11:17 < dgollub> Tuju: not quite sure what you mean?
11:17 < Tuju> nevermind
11:17 < dgollub> Tuju: right - but vformat plugin is not useable.. and if we freeze the xmlformat-schema today .. we have a hard time changing it in the feature
11:18 < dgollub> ok .. so to sum up:
11:18 < Tuju> yep, i fully understand it has it hasnt' seen much activity for long time
11:18 < dgollub> XMLformat-schema will not get frozen with 0.40
11:18 < dgollub> xmlforamt-plugin will not get released due this
11:18 < dgollub> xmlformat-plugin will get released spereatley.. and maybe we should consider to release just one objtype .. and add later further
11:19 < dgollub> the vformat-plugin get shipped with xmlformat-converters disabled by default with 0.40
11:19 < bricks> ok
11:19 < dgollub> we advice packagers to not package xmlformat-plugin and not to enable the vformat-xmlforamt converters
11:19 < Tuju> what i wonder is that can the rest be safely frozen as there has not been much of real life testing with it recently.
11:19 < dgollub> and we ship the file-sync and syncml plugin i would say with 0.40
11:20 < dgollub> internally we can keep testing some xmlformat-converters stuff due to have some epxerience with the capabilities handling
11:20 < dgollub> but no xmlformat-schema issue or vformat-conversion issue will block 0.40
11:20 < dgollub> Tuju: could you help here in cleaning up things in wiki .. anything which tights opensync  directly to xmlformat? .. it's a spereated thing now
11:21 < Tuju> yep, then there is still time to make final fixes to api if needed.
11:21 < dgollub> and also move xmlformt tickets to a different milestone
11:21 < dgollub> and also a new milestone/roadmap for vformat plugin?
11:21 < Tuju> sure
11:21 < Tuju> you mean that xmlformat is its own beast now, could be used apart of opensync?
11:21 < dgollub> and also document somewhere that synchrnoization between different formats without  xmlformat-plugin (and vformat-converters when vformats einvoveld) is not possible
11:22 < dgollub> Tuju: yes
11:22 < Tuju> ack
11:22 < dgollub> Tuju: and nobody is restricted to use this xmlformat-crap :P
11:22 < dgollub> if someone provides an alternative which works.. i'm more then happy to use it ;)
11:22 < Tuju> dgollub: you mean forced
11:22 < dgollub> yeah
11:23 < Tuju> put AI's for me about those.
11:23 < dgollub> AI tuju: remove traces of tight XMLFormat dependecny of OpenSync - XMLFormat is since today a different beast
11:24 < bricks> meeting closed?
11:24 < dgollub> AI tuju: screen bugs (maybe ask fm for help) and reassign xmlformat and vformat to their one milestons
11:24 < dgollub> yeah.
11:24 < dgollub> i guess we're done
11:24 -!- bricks changed the topic of #opensync to: http://opensync.org/ 0.38 | http://libsyncml.opensync.org/ 0.5.0 | http://libwbxml.opensync.org/ 0.10.0 | http://opensync.org/wiki/FAQ | http://pastebin.com/