meetings/irc: opensync-20081230.log

15:03 -!- dgollub changed the topic of #opensync to: OpenSync project IRC meeting | please no support Question - this is a moderatated
          session
15:03 < dgollub> Samm: lets discusss this later
15:03 < ianmartin> Samm, I'm looking at writing better plugin development docs.  would be happy to help
15:04 < dgollub> ok - who's is present?
15:04 < dgollub> (let's start)
15:04  * ianmartin present
15:04  * dgollub present
15:04  * ChrisH present
15:04  * Samm present
15:04 < kaarposoft> present
15:05 < dgollub>    1. Action Items from previous Meetings
15:05 < dgollub>           * AI dgollub: assemble list of terms. to use for developer API
15:05 < dgollub>                         documentation
15:05 < dgollub>           * AI dgollub: introduce example-plugin using static-capabilities
15:05 < dgollub>           * AI dgollub: add capabilities chapter as requested by gcobb
15:05 < dgollub>           * AI dgollub: document each plugin function - which bits of
15:05 < dgollub>                         information can be set/reported at each point - entry
15:05 < dgollub>                         point documentation
15:05  * bricks present
15:05 < dgollub> ok  - i feel pretty bad ... my AI list is growing and growing
15:06 < dgollub> ianmartin: i have seen that you committed some stuff for the whitepaper ... did this contain also capabilities chapter
                 related stuff?
15:06 < ianmartin> No, but working on that now
15:06 < dgollub> (didn't managed to read your changes... i discovered the svn hook script was broken to compile the latex document on the
                 server)
15:06 < ianmartin> so I can take add capabilities chapter as requested by gcob
15:06 < dgollub> cool .. can reassing this AI to you?
15:07 < dgollub> i guess you already good the idea how the stuff is supposted to work .. at list the opensync-devel gave a very good picture
15:07 < dgollub> -good +got
15:07 < ianmartin> can write something, ask wher I find gaps and then you can review to make sure it all makes sense
15:08 < dgollub> ok cool
15:09 < ianmartin> dgollub, I'm missing some styles for the latex stuff - will ask you about this later
15:09 < dgollub> ok - no problem .. style is not so important as content is :)
15:09 -!- absence [i=torgeihe@horisont.pvv.ntnu.no] has joined #opensync
15:09 < dgollub> ok still try to do the other stuff...
15:10 < dgollub> maybe i do the example static-capabiliteis stuff before wasting more time on bugfixing
15:10 < dgollub> ok .. next topic
15:10 < dgollub>    2. Doxygen / API
15:10 < dgollub>           * Status
15:10 < dgollub>           * Any trivial work left to give away?
15:10 < dgollub> bricks: can you give any status on the api documentation front?
15:11 < bricks>  most of all c files are cleaned of doxygen annotations
15:11 < bricks> currently i am working on opensync module
15:11 < bricks> which i'll finish in some minutes
15:11 < bricks> all module functions are now internal
15:11 < dgollub> ok cool - thanks a lot                                                                           
15:11 < bricks> we need a lot of documentation
15:11 < bricks> e.g. engine isn't documented at all
15:12 < dgollub> i know :( .. i'll in middle of engien hacking ... i'll do the engine documentation
15:12 < bricks> and the engine part is very importent ;)
15:12 < dgollub> but is there already full doxygen "coverage" ... speak: does doxygen.log spots all missing/wrong doxygen documetnation?
15:13 < bricks> have to take a look at
15:13 < dgollub> ok
15:13 < bricks> two "modules" are still open to move the doxygen stuff from the c files
15:13 < dgollub> is there anything trivial work missing we could announce as easy-task for volunteers? (no programming skills required and
                 stuff like that..)
15:13 < bricks> version and plugin
15:14 < bricks> it is trivial (more or less) but cost et least one our
15:14 < bricks> hour
15:14 < dgollub> ok .. should we give this task to someone else? so you can concentrate on the more complicated stuff?
15:14 < bricks> don't know
15:14 < bricks> i can finish this
15:14 < dgollub> ChrisH: could you help here again?
15:14 < dgollub> ChrisH: iirc you already did some work here?
15:15 < ChrisH> I did some before.
15:15 < bricks> you can run make DoxygenDoc and see which "modules" are ready
15:15 < dgollub> could you take care about version and plugin?
15:15 < ChrisH> I can take another module. I cannot promise a timeline.
15:15 < dgollub> just do module by module ..once a module is finsihed send a patch to opensycn-devel so we can commit it
15:16 < bricks> btw. i updated a lot of doc but i don't know if it is right at all
15:16 < dgollub> but at least we can release bricks from that trivial stuff and let him do some more complicated stuff
15:17 < dgollub> bricks: people will complain soon enough if they read it :) no worry .. at least we have some docu
15:17 < bricks> ;) ok
15:17 < dgollub> by time i try to proofread this .. but this might take some more days before this happens
15:18 < dgollub> ChrisH: so it's ok wit you to do "version" and "plugin" module? speak: move doxgen stuff from .c files to .h files?
15:18 < ChrisH> yes.
15:18 < dgollub> AI ChrisH: offload bricks by moving doxygen annotation of "version" and "plugin" modules to header file
15:18 < dgollub> ok great
15:18 < bricks> please note if any code is not documented
15:19 < bricks> or if there are _ functions
15:19 < bricks> e.g. _osync_do_anything
15:19 < dgollub> ChrisH: like you did already in soem engien function which was #if 0 .. this was fully correct and very appreciated
15:19 < bricks> i renamed all _functions and added them into the private header
15:20 < dgollub> by reanming you mean _osync_blubb -> osync_blubb - right?
15:20 < bricks> right
15:21 < bricks> or if the are named like _do_something -> osync_do_something
15:22 < ChrisH> Wont that break anything?
15:23 < bricks> sometimes yes
15:23 < dgollub> ChrisH: right .. it would be if you do for now just the doxygen stuff
15:23 < dgollub> ChrisH: i guess that's easier... we do the _function stuff later...  i would suggest
15:23 < bricks> and write some comments if there are functions with _
15:24 < dgollub> ok - anything else?
15:24 < dgollub> next topic?
15:25 < dgollub> ok next.
15:25 < bricks> yes
15:25 < dgollub>    3. Bug/Ticket Status
15:25 < dgollub>           * Bugs against milestone 0.39 and 0.40 doesn't reflect roadmap
15:25 < dgollub>             defined guidelines
15:25 < dgollub>             o lots of bugs with severity normal assigned to milestone 0.39
15:25 < dgollub>           * New hot bugs?
15:25 < dgollub>           * XMLFormat and vformat?
15:25 < dgollub> i usual do ticket query like this:
15:26 < dgollub> opensync.org/roadmap -> Active tickets for milestone xyz .. and then group by severity
15:26 < dgollub> and for 0.39 and 0.40 there are lot "normal" bugs                                                         
15:26 < dgollub> the roadmap milestone describes that such bugs not get fixed
15:27 < dgollub> i already screend some bugs
15:27 < dgollub> if you file bugs which have critical severity .. please make sure you also tag them with critical severity
15:27 -!- LoneStar [n=xinzhen@114.92.160.17] has quit [Remote closed the connection]
15:27 < dgollub> otherwise it might happen that i completely forgot about them
15:28 < dgollub> fm is unfortuantely not around... but it would be great if someone could screen the bugs within the next days
15:28 < dgollub> ... or even screen your own reports :)
15:29 < dgollub> * XMLFormat and vformat? ... there are really loooooots of bugs
15:29 < bricks> yes and i have a question about notes. which formats exists for notes?
15:29 < dgollub> if you have time feel free to look into those... cstender seems to be out of time - so don't hesistate to touch vformat if
                 you like... but it's not high prio.
15:30 < dgollub> bricks: vnote11 (IRMC specific) / memo / tomboy-note ... and then the discussion about vJournal
15:30 < dgollub> bricks: there was recentlry a thread on opensync-devel about this...
15:30 < bricks> that's the part i had in mind
15:30 < dgollub> bricks: i'll send you a pointer to the thread alter... (offtopic)
15:31 < dgollub> bricks: just remind me after the meeting
15:31 < bricks> ok thanks. additionally i would like to say that vnote is also totally broken
15:32 -!- absence [i=torgeihe@horisont.pvv.ntnu.no] has quit ["leaving"]
15:32 < dgollub> i could imagine that
15:33 < bricks> next topic?
15:33 < dgollub> * New hot bugs?
15:34 < dgollub> bricks: i filled vnote is also totally broken as item in the minutes
15:34 < bricks> ok
15:34 < bricks> :)
15:34 < dgollub> other hot bugs which might slipped?
15:34 < dgollub> i'm still fighting with mixed-objtypes ... so maybe i was missing something
15:34 < kaarposoft> 1003 ?
15:34 < dgollub> whats 1003 about? the syncml warning thing?
15:35 < kaarposoft> infinite loop...
15:35 < bricks> http://opensync.org/ticket/1003
15:35 < kaarposoft> ... with syncml, yes
15:35 < dgollub> ah this one.. is there no timeout?
15:35 < dgollub> kaarposoft: could you keep this running for at least 30minutes? ;)
15:36 < dgollub> arg.. don't use syncml-client as component.. this used to be another syncml plugin
15:36 < dgollub> we need to drop syncml-client
15:36 < dgollub> oh wait
15:36 < dgollub> michael is assinged..
15:36 < dgollub> ok then it's fine
15:36 < kaarposoft> I do not use syncml-client but syncml-obex-client
15:37 < dgollub> ok ... other stuff? e.g. engine related?
15:37 < dgollub> slow-sync not working or fake conflicts? duplicates?
15:38 < dgollub> ok .. next topic?
15:38 < dgollub> next ..
15:38 < kaarposoft> Well, 1003 is actually intial slow-sync not working for Nokia 6280
15:38 < kaarposoft> I have no clue if it is engine or syncml releated.
15:38 < dgollub> kaarposoft: please state in the bug if this cause an timeout after 30 minutes or not
15:38 < dgollub> kaarposoft: if this not cause a timeout after 30 minutes -> engine
15:38 < dgollub>    4. Splitting XMLFormat-plugin out of OpenSync?
15:38 < dgollub>           * introduce format plugin merger/demerge function pointers
15:38 < dgollub>           * drop "internalFormat" from Engine
15:38 < dgollub>           * for 0.40?
15:38 < kaarposoft> Will do
15:39 < dgollub> since the quality of xmlformat is not really brillant and very likely we'll see lots of change also after 0.40 ... and
                 also to be able to switch to other "internal formats" in future i thought about dropping xmlformat
15:39 < dgollub> ... from /trunk
15:40 < dgollub> and keep it completely isolated from /trunk
15:40 < dgollub> we keep the xmlformat-api to assemble the format
15:40 < dgollub> this would also turn out that the merge/demerge calls needs to turn into ObjFormat specific function calls
15:41 < kaarposoft> is xmlformat not the "canonical" data format? I mean if everything (eg Vxxx) else fails, then xmlformat should work?
15:41 < dgollub> no not only .. currently it's the only format which allows us to merge/demerge changes
15:42 < dgollub> and it's the only format which allows "sane" comparsion and mapping...
15:42 < dgollub> the vformat compare function today consists of memcmp() which is just a joke
15:42 < dgollub> xmlformat_compare() is pretty smart.. and does weak comparsion and returns SAME/SIMILAR/MISMATCH
15:42 < dgollub> which is important
15:43 < kaarposoft> exactly. so why throw it out of trunk?
15:43 < dgollub> if we have bugs in xmlformat_compare() or need to enhance the xmlformat-schemas we have to release opensync
15:43 < dgollub> (... i mean to fix the bug .. we need to release opensync)
15:44 < dgollub> it's much less maintenacne effort to release xmlformat-plugin seperated
15:44 < kaarposoft> well, I have no strong opinion either way - just trying to understand (-;
15:44 < dgollub> also the isolation is important later... if someone wants to use the opensycn engine without our xmlformat crap
15:44 < dgollub> bricks: what do you think?
15:44 < dgollub> ianmartin: thoughts?
15:45 < bricks> i don't know if it is possible
15:45 < bricks> yes of course we can maintain it outside trunk
15:45 < bricks> but the converter does heavily depend on xmlformat
15:46 < bricks> and the merger too
15:46 < dgollub> right
15:46 < bricks> and these are important parts of osync
15:46 < dgollub> but if we introduce merger/demrge format-plugin functions .. and keep the internalFormat stuff in the engine for now this
                 should still work
15:46 < ianmartin> surely the internal format is key to opensync
15:47 < bricks> if a user has to install xmlformat to use opensync
15:47 < dgollub> actually the conversion path should be able to handle this without that we have to hardcode an internal format
15:47 < bricks> then i don't think we should split it form trunk
15:47 < dgollub> bricks: thats more a packaging thing.. vformat plugin would recommed/require for isntance the xmlformat plugin
15:47 < bricks> dgollub: yes it should but it doesn't
15:48 < bricks> and the conversion code is really really not understandable
15:48 < ianmartin> but what about the archive?
15:48 < dgollub> ianmartin: the archive stores everything
15:48 < dgollub> bricks: yeah .. another point to make sure it's independent of xmllformat :)
15:49 < ianmartin> indeed, so you need an internal format that supports everything
15:49 < dgollub> ianmartin: why?
15:49 < dgollub> ianmartin: was this with regard to the archive?
15:49 < ianmartin> dgollub, yes
15:50 < dgollub> if the merge/demerge can be done with any format-plugin ... why should the archive not handle this?
15:50 < dgollub> the problem i see with the internalFormat and the xmlformat is that we restrict our self to xmlformat-only
15:51 < dgollub> this should not be the case.. since this would avoid other people/project/companies to use opensync as synchronization
                 logic
15:51 < dgollub> maybe the want to support a new set of data ... a new objtype/content-type
15:52 < dgollub> they have two formats to convert.. and also to deal with capabilities.. with the current implementation it would be not
                 possible for them to use the merger and archive
15:53 < dgollub> and it shouldn't be so hard to call instaed of osync_xmlformat_merge() a format-plugin format pointer
15:53 < dgollub> the only ciritcal thing which i agree on is the current conversion path implemetnation
15:54 < dgollub> if we would drop the "internalFormat" which is hardcoded in the engine to force all formats to get converted first to
                 xmlformat.. that this might cause problem
15:54 < ianmartin> so you would need to know if a format-plugin can merge or no
15:54 < dgollub> yes
15:54 < bricks> ok i guess we need to rewrite the conversion stuff
15:54 < dgollub> but thats quite easy .. if the format plugins doesn't has a merge/demrge function regisrtesd -> not supported
15:54 < dgollub> bricks: also an idea
15:55 < dgollub> so the longterm goal would be a conversion path which is smart enough to build a conversion path via a format which is
                 able to convert first to a format which is able to merge/demerge
15:56 < dgollub> and then convert to the target format
15:56 < dgollub> but this is only required if we drop the "internalFormat" thing
15:56 < bricks> yes and maybe a direct way without internal conversion
15:56 < bricks> yes  
15:56 < dgollub> so first i would suggest to move the merge/demerge stuff into the format-plugin
15:56 < dgollub> and then decide if we want to do rewrite conversion path from scratch
15:57 < dgollub> what do you think?
15:57 < bricks> ok for me
15:57 < dgollub> ok cool
15:57 < bricks> i don't like the curent code of the converter ;)
15:57 < dgollub> bricks: are you interested? :) i know you have expereince in that space
15:57 < ianmartin> sounds ok, but also another obstacle to getting something actually released
15:57 < bricks> merger/demerge <- no eperience
15:58 < bricks> i don't even know when to use it
15:58 < dgollub> ianmartin: yeah .. but this would cause a major api break (maybe)
15:58 < dgollub> ianmartin: and we coudl also decide to release 0.40 earlier .. indepednet of the qualtiy of xmlformat-plugin
15:58 < dgollub> ianmartin: we just say .. opensync is ready ... and you're safe doing backups - but conversion between pim formats is
                 completely unsafe
15:58 < dgollub> ianmartin: due to xmlformat
15:59 < dgollub> ianmartin: and there are lot of people actually just want to sync first abc-sync to file-sync
15:59 < bricks> we should provide a opensync version which is capable of api/abi stability in case of internal format chages
15:59 < dgollub> bricks: you don't need to touch merger/demerge stuff .. just introduce format-plugin interface
16:00 < ianmartin> dgollub, indeed just getting information of a peer and into file-sync is qutie useful!
16:00 < dgollub> s... which allow to call the merger of the format instead of the hardcoded one - i'll point you to the code which you have
                 to replace in the engine once you introduce the interface
16:00 < dgollub> ianmartin: for some crazy reason more people asking for that then acutal sync :)
16:01 < dgollub> so the main idea is ... to get opensync 0.40 out with a stable vformat plugin
16:01 < dgollub> so people which want to write their sync application without the vformat-crap and sync other staff can pickup
16:01 < bricks> right
16:02 < dgollub> also that people can write sync stuff which is independent of xmlformat stuff
16:02 < dgollub> the conversion path is able to convert via several formats... so i don't want to keep the impression xmlformat is the only
                 thing to be used in opensync
16:03 < dgollub> if someone shows up with a new format-plugin which is convertingn vCalendar and iCalendar flawless.. perfect! it doesn't
                 needs to be done via xmlformat
16:03 < bricks> would be great
16:03 < bricks> i like xmlformat because it is xml
16:03 < bricks> but i don't think it fits all need
16:03 < bricks> s
16:03 < dgollub> so we're still open to vCalendar <-> iCalendar <-> xmlformat-event <-> libgcal-format-event
16:05 < dgollub> ianmartin: so this could be acutally speed up to get things released.. check the 0.39 roadmap .. there are approx. 9
                 tickets only for not xmlformat or vformat related stuff
16:05 < dgollub> another cool thing is .. we don't have to freeze the xmlformat schema with 0.40 :)
16:06 < dgollub> bricks: so do you take the AI for the merge/demerge functios for format plugins?
16:07 < ianmartin> in above example at the moment only xmlformat-event can do (de)merger so xmlformat-events are stored in the archive
16:07 < dgollub> bricks: i'll assist you then when it comes to strip the merge out of the engien and do the function calls and implement
                 the merging in the xmlformat
16:07 < bricks> don't have a clou about the parameters
16:07 < dgollub> ianmartin: right
16:07 < dgollub> bricks: i'll give you a protoype declartion for this later
16:07 < bricks> ok then it's fine
16:08 < dgollub> AI bricks, dgollub: introduce merger/demerge format-plugin functions - make merging independent of xmlformat
16:08 < ianmartin> then i add a new plugin vCalendar <->libgcal-format-event with merger/demerger, but somehow we must still go via
                   xmlformat-event so use the info in the archive
16:09 < dgollub> ianmartin: for that we have "internalFormats" in engine ...
16:09 < dgollub> ianmartin: for time being... but later the conversion-path-builder should handle that
16:10 < ianmartin> ok, so first step is add merger/demerger to plugin interface
16:10 < ianmartin> initially this will only apply to xmlformat
16:10 < dgollub> http://opensync.org/browser/trunk/opensync/engine/opensync_engine.c#L1242
16:10 < dgollub> ianmartin: correct
16:10 < ianmartin> and we the path will still always go via xmlformat for now
16:11 < ianmartin> but at later date path can be rewritten to be more intelligent
16:11 < dgollub> right     
16:11 < bricks> right
16:11 < dgollub> the link i sent will make sure it will go always via xmlformat
16:11 -!- Samm [n=chatzill@129-170-195-217.cust.centrio.cz] has quit [Read error: 60 (Operation timed out)]
16:11 < bricks> if it isn't data objtype ;)
16:12 < dgollub> bricks: haha .. this changed a bit the last days :)
16:12 < dgollub> http://opensync.org/browser/trunk/opensync/engine/opensync_engine.c#L192
16:12 < ianmartin> so one day these internal formats will disappear?
16:13 < dgollub> http://opensync.org/browser/trunk/opensync/engine/opensync_engine.c#L221 - detect encapsulated formats .. right now
                 limited to "data"
16:13 < bricks> yes
16:13 < dgollub> ianmartin: yes - when the conversion-path builiding logic is able to make sure merging is done at the right place
16:15 < bricks> nice code so file-sync has to use always data
16:15 < dgollub> bricks: but later i try to get rid of the "data" stuff as well :) but not for 0.40
16:15 < dgollub> bricks: no
16:15 < dgollub> bricks: or.. yes right
16:15 < dgollub> bricks: but only temp. .. if i remove this !strcmp("data") thing the testsuite explodes
16:16 < dgollub> the mock-format plugin is not clean
16:16 -!- juergbi [n=juerg@84-73-62-122.dclient.hispeed.ch] has joined #opensync
16:16 < dgollub> it crashes in the detect() call ... i'll fix that once my mixed-objtype stuff is copmleted
16:17 < dgollub> but later every format should be checked for encapsulated formats
16:17 < dgollub> -format +objtype
16:18 < dgollub> so even if file-sync reports "contact" since it has per directory different objtypes ... the detect() functions check if
                 the "file" format encapsulates something elese...
16:18 < bricks> ok i guess we have a common view of the format conversion
16:18 < dgollub> ah wait.. there is anotehr thing
16:19 < dgollub> right now we do two times detect.. which is also ugly
16:19 < dgollub> but i'll fix that later
16:19 < dgollub> first for the objtype detection.. later to find the encapuslated formats
16:19 < dgollub> ok .. next topic
16:20 < dgollub>    5. Capabilities & Merger testing
16:20 < dgollub>           * Request for real-life testing of capabilities and merger
16:20 < dgollub>           * Generating ~/.opensync/groupX/Y/capabilities.xml by hand
16:20 < dgollub>           * Check for data-loss (on slow-sync)
16:20 < dgollub>           * Check for duplicate (on slow-sync)
16:20 < dgollub>           * Check for conflicts (on slow-sync)
16:20 < dgollub> maybe we should postpone this one
16:20 < bricks> ok
16:20 < dgollub> since we agreed on touch the merger stuff
16:21 < dgollub> ianmartin: is the merger/capabilties stuff working for you?
16:21 < dgollub> ianmartin: the stuff we have today?
16:22 -!- amilcar [n=amilcar@dslb-092-076-114-247.pools.arcor-ip.net] has joined #opensync
16:22 < dgollub> ok .. we run out of time
16:22 < ianmartin> dgollub, not sure, so much goes missing with vformat not getting it's config I stopped checking it
16:23 < dgollub> ianmartin: i see.. i reviewed your bug. another point to rewrite the conversion-path buildier :)
16:23 < bricks> from scratch!
16:24 < dgollub> right :P
16:24 < dgollub> ianmartin: but ocne you run discover your member has a capabilites.xml right?
16:24 < dgollub> ok next topic"
16:24 < dgollub>    6. Plugin Configurations
16:24 < dgollub>           * Static / Dynamic configuration
16:24 < dgollub>           * Resource configuration
16:24 < dgollub>           * Documentation
16:24 < dgollub>           * Advanced Options
16:24 < dgollub>           * Option description (i18n)
16:24 < dgollub>           * Changes for 0.40?
16:24 < dgollub>           * Who takes care about this?
16:24 < dgollub> kaarposoft: around?
16:25 < kaarposoft> yes!                                                                                       
16:25 < dgollub> you brought about discussion about having different plugin configuration
16:25 < kaarposoft> Two points:
16:26 < ianmartin> dgollub, yes capabiltieis.xml is generated if you create an OSyncCapabilities during discover
16:26 < kaarposoft> 1) Currently we have the possible advanced config options for a plugin in the same file as the actual option settings
                    for a group.
16:26 < kaarposoft> 2) We need better doc of plugins and their capabilities.
16:26 < kaarposoft> two suggestions:
16:27 < kaarposoft> 1) split config file in one static for the plugin and one dynamic for group
16:27 < kaarposoft> 2) move doc out of config file and into localized language files
16:27 < kaarposoft> over...
16:28 < dgollub> ok what's the content of the dynamic one?
16:28 < kaarposoft> the ACTUAL settings of the options for a specific group
16:29 < dgollub> you mean member?
16:29 < bricks> an static is e.g. a path to thunderbird
16:29 < kaarposoft> sorry, yes, member, not group.
16:29 < kaarposoft> Eg. this
16:29 < kaarposoft>     <AdvancedOption>      <DisplayName>SyncML Version</DisplayName>      <MaxOccurs>2147483647</MaxOccurs>
                    <Max>2147483647</Max>      <Name>SANVersion</Name>      <Type>string</Type>      <ValEnum>1.0</ValEnum>
                    <ValEnum>1.1</ValEnum>      <ValEnum>1.2</ValEnum>      <Value>1.1</Value>    </AdvancedOption>
16:30 < kaarposoft> would be split into dynamic:
16:30 < kaarposoft> <Value>1.1</Value>
16:30 < kaarposoft> language:
16:30 < kaarposoft> <DisplayName>...
16:30 < kaarposoft> and the rest in the static plugin def
16:31 < dgollub> ok - where is the static one located? in the member direcotries .. or wouldn't it better to store this a distro direocty
                 .. for easier update?
16:31 < kaarposoft> I think this is a much cleaner split, and will be easier to maintain
16:32 < kaarposoft> yes, the static one and the localization ones should be in distro dir - they are static and never touched by the user.
16:32 < dgollub> e.g. /usr/share/libopensyncX/plugin/$plugin/advanced.xml
16:32 < kaarposoft> exactly
16:32 < dgollub> ok - pretty cool idea
16:33 < dgollub> i like the idea - are you interested in taking care about this?
16:34 < kaarposoft> and /usr/share/libopensyncX/plugin/$plugin/da-dk.xml , /usr/share/libopensyncX/plugin/$plugin/en-US.xml
16:34 < kaarposoft> I have too much on my plate already with the mozilla plugin and frontend )))-:
16:34 < kaarposoft> ... and very little knowledge of the internal workings of OpenSync
16:35 < dgollub> kaarposoft: best time to start with it :)
16:35 < dgollub> the configuration stuff is not that hard... it's only a bit libxml - but the code you need to know already exists
16:36 < dgollub> (expect the i18n thing)
16:36 < dgollub> you just need to copy&paste and adjus tthe code
16:36 < dgollub> thats it
16:37 < dgollub> and if you get stuck .. just drop a mail on opensync-devel .. i
16:37 < kaarposoft> I am sorry, but I would rather say no now, than do a half-hearted job. I think it is better that I stick to the mozilla
                    plugin
16:37 < dgollub> i'm sure somewone will help
16:37 < kaarposoft> But I can make a ticket with a more detailed description...
16:38 < dgollub> kaarposoft: the problem then is that this might not happen... since we already have a lot todo :/
16:38 < dgollub> and once opensync is doen we can help on mozilla-sync :P
16:38 < kaarposoft> I know )))-:
16:39 < dgollub> so i would be fine with the changes if you could at least try to start with it ... if there is any complicated outstanding
                 stuff left i'm sure someone could help fixing it
16:39 < dgollub> but we need someone how does detatiled implementation desciprtion/plan/API and then at least start with it
16:39 < kaarposoft> one big issue: this will impact all plugins, they will all have to change config files.
16:39 < dgollub> thats no big deal today
16:39 < dgollub> it's a big deal after 0.40
16:40 -!- Savago [n=adenilso@189-19-47-130.dsl.telesp.net.br] has joined #opensync
16:40 < kaarposoft> it's a big deal for me...
16:40 < dgollub> we don't care in 0.3x about plugin config difference
16:40 < dgollub> why? because you have to touch mozilla-sync?       
16:40 < dgollub> everyone which has a plugin in 0.3x space would need to touch the plugin
16:40 < dgollub> but better to touch it in 0.3x then in 04.x
16:41 < kaarposoft> OK, what I can offer is this: I will look into the issue, try to make a plan for the API etc, and maybe - just maybe -
                    a patch...
16:41 < kaarposoft> why? because you have to touch mozilla-sync?  <-- No, because I have to touch all the others!
16:42 < bricks> no you don't have to touch the others
16:42 < bricks> that has to be done by the other plugin developers
16:42 < bricks> like in the past
16:42 < dgollub> right
16:42 < bricks> where we changed the config in nearly every osync version ;)
16:42 < dgollub> kaarposoft: the only thing you should do .. describe what needs to be changed
16:43 < kaarposoft> ok, fair enough. Anyway, as I said: I will have a look, but no promises
16:43 < dgollub> ok cool
16:43 < dgollub> feel free to send even patches in of little changes .. not of the entire implementation. .so we have at least some pieces
                 of the implemetnion where to continue
16:44 < kaarposoft> should i put the proposed description etc. in opensync-devel, on wiki, or ?
16:44 < dgollub> opensync-devel@ easier to reply and add comments
16:44 < bricks> ticket and devel would be nice
16:44 < kaarposoft> ACK
16:44 < dgollub> yeah ticket to track their is something missing before realsing 0.40
16:45 < kaarposoft> 3 * ACK
16:45 < dgollub> ok next topic
16:45 < dgollub>    7. User vs. Developer documentation
16:45 < dgollub>           * terminology of target audience
16:45 < dgollub>                 o OpenSync core developers
16:45 < dgollub>                 o Plugin Developer (Format & Connectors)
16:45 < dgollub>                 o Frontend/Server Developer
16:45 < dgollub>                 o "Beta"-Tester (includes Alpha-Tester)
16:45 < dgollub>           * what is of interested for the Developer?
16:45 < dgollub>           * what is of interested for the User?
16:45 < dgollub>           * what to document at all?
16:45 < bricks> postpone?
16:45 < dgollub>                 o OpenSync API? (Plugin & Frontend/Server API)
16:45 < dgollub>                 o usage of osynctool/msynctool?
16:46 < dgollub>                 o plugin configuration?
16:46 < dgollub>                 o "Should Suse document Apache? I don't think so."
16:46 < dgollub> yeah
16:46 < dgollub> Tuju is not around.. i guess he was raelly intrested in this
16:46 < kaarposoft> postpone? - yes, running a bit late here ((-;
16:46 < dgollub>   8. Next IRC Meeting
16:46 < dgollub>           * Next IRC Meeting
16:46 < dgollub>           * Who takes minutes/backup?
16:47 < dgollub> ok .. next week would be regular dates
16:47 < dgollub> 2nd calendar week
16:47 < dgollub> need to check which weekday was even
16:47 < kaarposoft> can't promise to be there in IRC, but I will try...
16:48 < dgollub> ok it's a thursday
16:48 -!- kaarposoft [n=kaarposo@x1-6-00-1c-f0-f7-76-a0.k592.webspeed.dk] has left #opensync ["Bye"]
16:49 < dgollub> Next IRC Meeting: 2009-01-08T09:00:00Z
16:49 < dgollub> Minutes taker? Backup?
16:50  * ChrisH on vacation then.... offline.
16:51 < dgollub> kk .. Minutes: TBA
16:51 < bricks> I can take care of the meeting next time
16:51 < dgollub> ok cool
16:51 < dgollub> Minutes: bricks Backup: dgollub
16:51 < dgollub> meeting closed
16:51 < bricks> ok