meetings/irc: opensync-20090114.log

20:05 -!- dgollub changed the topic of #opensync to: OpenSync IRC project meeting | please no support question - or bug reports
20:06 < azeem> wow, I managed to be around during a meeting
20:06 < azeem> pure luck
20:06 < dgollub> ok .. lets start - who's present?
20:06  * dgollub present
20:06  * bricks present
20:06  * savagobr present
20:07 < dgollub> 1. Action Items from previous Meetings
20:07 < dgollub>           * AI dgollub: assemble list of terms. to use for developer API
20:07 < dgollub>                documentation
20:07 < dgollub>           * AI dgollub: introduce example-plugin using static-capabilities
20:07 < dgollub>           * AI dgollub: document each plugin function - which bits of
20:07 < dgollub>                information can be set/reported at each point - entry point
20:07 < dgollub>                documentation
20:07 < dgollub>           * AI dgollub: doing engine hacking alread, do documentation once
20:07 < dgollub>                hacking is done
20:07 < dgollub>           * AI dgollub: create proposal for new OSyncDB interface
20:07 -!- cstender [n=cstender@g229163141.adsl.alicedsl.de] has joined #opensync
20:07 < dgollub> hi cstender 
20:07 < bricks> hi cstender 
20:07 < cstender> hi dgollub 
20:08 < dgollub> ok .. my AI list is getting pretty long - but i don't want to truncate it .. those are task which need to be done
20:08  * cstender is currently reading tons of opensync-devel mails
20:08 < dgollub> unforutenly i didn't managed to do any of them - i'll turn them into tickets ... so volunteers can take-over before i do them
20:08 < dgollub> cstender: (hint: meeetiing .. you might want to focus on irc first)
20:09 < dgollub> * AI bricks: make osynctool synchronisation (multiply-)summary more
20:09 < dgollub>                intuitive (after dgollub has created a ticket ;-) )
20:09 < dgollub>           * AI tuju: screen bugs (maybe ask fm for help) and reassign
20:09 < dgollub>                xmlformat and vformat to their own milestones 
20:09 < dgollub> bricks: i forgot to create such ticket :(
20:09 < bricks> :)
20:09 < dgollub> i guess i'll create one .. but mark it as [TRIVIAL] ... so maybe someone else take it ....
20:09 < cstender> dgollub: ups, sorry
20:10 < dgollub> bricks: ... so you can focus on more complex stuff
20:10 < dgollub> AI dgollub: create for all not yet finished dgollub-AIs tickets
20:10 < dgollub> is Tuju around?
20:10 < bricks> maybe we should always create tickets for ais?
20:11 < dgollub> bricks: yeah .. would be better
20:11 < bricks> easier to track
20:12 < dgollub> ok .. tuju nor fm is around - but i guess there didn't happend a lot ...
20:12 < dgollub> cstender: did you managed to get a overview of the vformat bugs?
20:13 < cstender> well, it's on my todo for this evening
20:13 < dgollub> ok - cool
20:13 < dgollub> let's continue - next topic:
20:13 < dgollub> 2. User vs. Developer documentation (from (last) last meeting)
20:13 < dgollub> should we postpone this again? since Tuju isn't around?
20:14 < dgollub> ChrisH around?
20:14 < dgollub> any objections to skip this one? i would like to have at least some of the main-wiki-drivers around
20:15 < dgollub> and frontends folks (e.g. henrik)
20:15 < savagobr> postpone it.
20:15 < dgollub> ok cool
20:15 < dgollub> next topic:
20:15 < dgollub>    3. FOSDEM 2009
20:15 < dgollub>           * anyone planning to attend FOSDEM?
20:15 < cstender> sorry, no time this year
20:16 < bricks> it's in bruessel -> no
20:18 < savagobr> By the way... is any 'opensync-hackers' meeting planned for this year?
20:18 < dgollub> hmm good question
20:19 < dgollub> we're really spread all around  the world
20:19 < savagobr> I think it would be cool to have *at least* one yearly meeting.
20:19 < dgollub> reg. fosdem i try to get their ... i hope to meet at least a few opensync interested people
20:19 < dgollub> savagobr: which location? brazil? ;)
20:20 < savagobr> Heh, at some paradise-like beach with cold beer? :-D
20:21 < dgollub> http://www.linuxuwb.org/thewiki/LinuxUWBUserArch200703 <- here?
20:21 < savagobr> I will attend Bossa Conference this year. Anyone else?
20:22 < dgollub> i guess it's quite expensive  to bring all people to porto de galinhas ...
20:22 < savagobr> Yeah... damn expensive.
20:22 < dgollub> savagobr: can't afford it without travel budget ...
20:23 < dgollub> maybe at some later point when 0.40 we should have a release party or something like that and plan 0.4x
20:23 < dgollub>    4. XMLFormat independent OSyncCapabilities interface
20:23 < dgollub>           * What needs to be done to make merging/demerging protocol/device
20:23 < dgollub>             specific?
20:25 < dgollub> so .. this topic is something we need to address before 0.40
20:25 < dgollub> since the current implementation brings  a direct dependency to the xmlfromat
20:25 < dgollub> which we should try to avoid
20:26 < dgollub> syncml plugin has lots of code to map "vformat"-fieldnames to XMLFormat field names
20:26 < dgollub> thats not clean ... since the syncml should not have to deal with any vformat or xmlformat stuff
20:26 < dgollub> same for evo2-sync, kdepim-sync and all other plugins
20:27 < dgollub> if we would do the capabilities reporting in a format "native" way we would have several benefits:
20:27 < dgollub> - independent of xmlforamt
20:27 < dgollub> - no additioanl code in sync plugin required to map to specific format (e.g. xmlformat)
20:28 < azeem> oops, I'll be at FOSDEM
20:28 < dgollub> - if most format bring their own merge/demerge function we would have the "entire" entry cached before the first conversion
20:29 < dgollub> the question is how to implement this?
20:30 < dgollub> the capabilities information is in most cases not only format specific - it's also protocol/device/application specific
20:30 < dgollub> maybe we should start discussing "static" capabilities
20:31 < dgollub> right now they write xmlformat to describe the capabilities
20:31 < dgollub> which i guess i still fine for certain sync-plugins - e.g. the google plugin
20:31 < dgollub> savagobr: do you have any google interface to get capabilities information - or is this just a fixed thing?
20:32 < savagobr> Do you mean which fields/data are supported? Case positive, its fixed.
20:33 < dgollub> ok
20:33 < dgollub> i wonder if we should change the current capabilitis "stored" format
20:33 < dgollub> right now it's just a node list of all the xlformat names
20:34 < dgollub> to make it more format  independent it would instead store field names as a node content
20:34 < dgollub> something like:
20:34 < dgollub> <contact><field>TEL<field>...</contact>
20:35 < dgollub> (anyone has a XML syncml dump handy? which contains devinf?)
20:37 < bricks> sorry have to leave now
20:38 < bricks> cu
20:38 -!- bricks [n=bricks@xdsl-92-252-37-52.dip.osnanet.de] has left #opensync []
20:38 < dgollub> http://pastebin.com/m9d4f910
20:38 < dgollub> this is how the field capabilities in SyncML get described (truncatd)
20:39 < dgollub> so instad of writing capabilities like:
20:39 < dgollub> <contact><Address/><Name/><Telephone/></contact>
20:39 < dgollub> (which would only raelly useful with the xmlformat)
20:39 < dgollub> instead store the capabilities like this
20:40 < dgollub> <contact><PropName>Address</PropName><PropName>Name</PropName><PropName>Telephone</PropName></contact>
20:40 < dgollub> additionaly we can later extend this format with information like the max size
20:40 < dgollub> so very much like syncml is doing this today
20:41 < dgollub> the benefit of storing it this way is: that the format-plugin would get the informatio what to merge/demerge in their native format .. and don't need to map field-names to XMLFormat names
20:42 < dgollub> since we have to do anyway the merging before the conversion to a common format i guess it's not really hard to implement something like that...
20:42 < dgollub> what do you think?
20:43 < dgollub> any question? ;)
20:44 < savagobr> Hum... basically, is just about moving the description of format structure from the XML tag to inside of its element?
20:44 < dgollub> yep - at least for those plugins which don't use any standized format and still rely on the xmlformat plugin
20:45 < savagobr> Right now, which plugins support capabilities? file-sync? syncml?
20:45 < dgollub> but sync-plugin like syncml, evo2-sync and kdepim-sync would just repot their capabilities information untranslated in those fields
20:45 < dgollub> savagobr: evo2-sync, kdepim-sync(?), mozilla-sync(?)
20:46 < savagobr> ok.
20:46 < dgollub> syncml is not really using it activley... it's reporting the capabilities during sync - which needs to be implemented in the engine to handle
20:46 < dgollub> so far it was only designed to get field-capabilities during the discover phase
20:47 < dgollub> but in some cases it would be enough to just report which object types are avialble during the discover phase.. and provide the possibility that plugins can report capabilities until get_changes() got completed
20:48 < dgollub> i refactored some parts in the engine ... so we can soon support something like that - since merging and conversion and comparsion would be done after all changes got sent to the framework
20:49 < dgollub> i'll write a mail to -devel about this
20:50 < dgollub> i guess there are still some hidden details which break this idea
20:50 < dgollub>    5. Q & A format plugins
20:51 < dgollub> are there any question regarding format plugins? which   are not clear since the -devel discussion?
20:52 < dgollub> ok - then let's don't waste time :)
20:52 < dgollub> 6. Next IRC Meeting Date? Who takes the minutes / backup?
20:53 < dgollub> next meeting i guess is a thursday at 09:00Z
20:53 < savagobr> ouch! 5AM@my-tz.
20:53 < dgollub> Next Meeting: 20090122T090000Z
20:53 < dgollub> any volunteers for minutes for next time? backup?
20:54 < dgollub> minutes: dgollub
20:54 < dgollub> backup: ???
20:54 < dgollub> meeting closed