15:23 < dgollub> dannyK: we had a short discussion about getting several different mobile (gadgets) devices working out of the box.. and making use of hal 15:23 < ChrisH> Prahl you mentioned libsyncml from SVN is broken. When using 'syncml-http-server --sync text/x-vcalendar Calendar --port 9999' and start a sync from the mobile I -at least- see the calender entries on the screen. When doing a 'msynctool --sync syncmlfile --wait --multi' I only get 'ERROR: No synchronizable objtype' ... and I think I did a similar setup. 15:24 < dgollub> dannyK: since there are a lot devices which need kind of "probed" to identify there interfaces/services/capabilities we discussed what the best way would be to get this kind of information within hal.. 15:25 < dannyK> dgollub: +and what was the result of the discussion? 15:25 < dgollub> dannyK: there are addons/(pre)callouts and so on .. once you told me that there are disadvantes of calllouts .. since the merge their information after the device got announced ("Device Added")... 15:25 < dgollub> dannyK: actually the result is .. nobody has certain knowledge about hal and it's just a wasting time discussion with lots of meta information .. so no result at all ;) 15:26 < dgollub> i would like to ask you if you could give us a bried introducation what would be the best way to probe usb devices for certain interface or to idnetify them... 15:26 < dgollub> e.g. 15:26 < ChrisH> Is it shure that HAL will not be replaced with some other project? compare: hotplug, udev, ... 15:26 < dgollub> ChrisH: i certainlly doubt that... 15:27 < dgollub> -bried +brief 15:28 < dannyK> ChrisH: hal is no replacement for udev 15:28 < dgollub> dannyK: there is lot ofs code in several userspace protocl implementation based on libusb.. for example libpisock (pilot-link) or barry (for blackbarry) or gnokii for f-bus and so on... which could be used in hal addon... 15:28 < dgollub> i found the haldong for thos csr wirless mices... 15:29 < ChrisH> I know t hat HAL is no replacement for udev. But udev seems some replacement for hotplug 15:29 < dgollub> which merges some battery information within hal (insane isn't it?! ;)).. but before that it probes via libusb... 15:29 < dgollub> -haldong +hal addon 15:31 < dgollub> dannyK: i guess simple callouts isn't good option.. since the device get announced before the information get merged - right? 15:32 < dannyK> There are also callouts which can get called before probe a device. But not sure if this is what you want. 15:32 < dannyK> what exactly do want to probe? 15:32 < dannyK> should it be part of HAL or of a other package? 15:33 < dannyK> what info should it add to hal? 15:33 < dannyK> IMO it depends on such things how to implement it 15:34 < dgollub> it should add information like "sync capablities: palm-hotsync, barry, synce, syncml" 15:34 < dgollub> the code to identifiy those service are basicially available in shared libs which are using libusb ... to send certain usb control sequences... 15:35 < dgollub> not quite sure if hal wants to have yet another dependecy on 5 different libraries .. like libopenobex, libpisock, libbarray and so on... 15:36 < dgollub> so it's basically just some libusb code.. which does probing to identify if this service is avaible on this device. 15:36 < dannyK> is there no way to put all this in one lib which only use libusb? 15:36 -!- bricks [n=bricks@e04-laptop5.et.Fh-Osnabrueck.DE] has left #opensync ["Leaving."] 15:36 < dannyK> about how much LOC do we speak 15:37 < dgollub> maybe about 100 (or a bit less) lines of libusb for each implementation - not quite sure.. just wild guessing 15:38 < Jc2k> this wouldnt help for synce tho, right? 15:38 < dgollub> what you prefer it to get this directly inside of hal... or what about as addon? so those libraries bring hal addons and the fdi file. 15:39 < dgollub> Jc2k: if you write some libusb code which probe .. why not? ;) i'm no that familiar with the userspace implementaiton of the rdnis-lite module.. could you point me to the source.. or just check for libusb code.. 15:40 < Jc2k> dgollub: remember ipaq ;) 15:40 < dgollub> Jc2k: the kernel module? the usb serial thinkie? 15:40 < dannyK> not a addon, they get started after device was announced 15:41 < dannyK> Im not sure if it should be part of HAL 15:41 < Jc2k> whats the problem with probing from a callout and then using the API to add a new device node? 15:41 < dgollub> dannyK: sure about that? i tried read some hald code.. and i thought addons could be called before they get announced... 15:41 < Jc2k> or rather, an "end point" 15:42 < dannyK> and IMO not every lib should deliver an on callout/prober, would be better to put them together to one callout (performance reasons) 15:42 < dannyK> yes, addons get called after the device 15:42 < dannyK> prober get called before 15:42 < dgollub> dannyK: what about addon_is_ready() in hald_dbus.c? 15:43 < dgollub> it's calling manager_send_signal_device_added() or is this async... 15:43 < Jc2k> i really dont see how you are going to do this for devices that need a ppp connection and mRouter before you can "see" a syncml engine running there 15:44 < dgollub> Jc2k: ok thats another issue.. but for now i try to stick with more simple devices which don't require any ppp chat scripts to keep an ip connection ... this is more tricky or even impossible ;( 15:45 < Jc2k> luckily for synce ppp we should be ok cos we can just have a hal FDI that looks for ipaq driver 15:45 < dgollub> Jc2k: until i hand in the drop request for the ipaq driver ;) 15:45 < Jc2k> and it turns out the usermode rndis driver uses the same FDI (pretty much) as the kernel version 15:45 < dgollub> Jc2k: another downside is synce would only work on linux ;) 15:46 < Jc2k> dgollub: when an openbsd or freebsd user comes and offers to help.. 15:46 < Jc2k> until then, its tough. 15:46 < dgollub> if eveyrthing would run on libusb and using hal .. no problem at all ;) 15:47 < dgollub> so freebsd and solaris peeps would be happy ;) 15:47 < dgollub> the guys from sun already planned to add hal support for their gnome opensync gui (gnome-sync-tool) 15:48 < Jc2k> fun times. 15:48 < Jc2k> im having a hard time convincing john that i should spend time on conduit/opensync 15:49 < dgollub> you don't have to convince anyone .. it's opensource you should do what you think is the best ;) 15:51 < Jc2k> and that why there are 56 ways of doing everything, none that "just work" 15:51 < dannyK> dgollub: addons are the wrong place, because you don't want to run the whole time. You want to probe and exit the prober and not probe and let the addon runnin 15:51 < dgollub> dannyK: ah i see.. i forgot addons are running all the time. 15:52 < dgollub> dannyK: so which possibilies are left to call a proper and exit them .. and merge information before announcing the device? 15:52 < dannyK> you want a info.callout.preprobe or a prober directly in HAL 15:53 < dgollub> dannyK: which disadvantages would the callout.preprobe have compared to directly probe in HAL? (i see disadvantes when pulling tons of code inside hal directly.. you would have to maintain it for life :P ) 15:53 < dannyK> but for performance reasons you want only one prober for all these different libs (if possible) 15:54 < dgollub> dannyK: oh, we could narrow done the number of propers since we can check for certain usb interfaces and only run prober where it's safe that this device could make use of prober xyz... 15:54 < dannyK> disadvantages: not sure, maybe that the callout get called before hal runs prober 15:54 < prahal> dgollub, the thread initialized via osync_thread_start are given a g_mainloop as parameter. the only use of osyncThreadStopCallback is to kill this mainloop . As per the http://library.gnome.org/devel/glib/unstable/glib-Threads.html#g-thread-join I see the use of this g_main_loop as a mean to kill the thread (by killing the gmainloop) when the stop callback is fired up . But with current real g_idle_source_new this never trigger (be 15:54 < prahal> cause g_idle_source_new are not fired up if there are no other non idle source 15:55 < prahal> thus the need for a fake idle source that is triggered but behaves like an idle one (check return true with timeout 0, prepare returns true) 15:55 < dannyK> dgollub: have to check if the callouts block the device add process 15:55 < dannyK> as e.g. prober can do IIRC 15:56 < dgollub> prahal: could you points me again to your patch.. i'll have a more closer look on that 15:56 < prahal> otherwise we could just strip the g_idle_source . They are useless 15:56 < dgollub> dannyK: but prober would mean it would be directly inside in hal - right? 15:56 < prahal> http://prahal.homelinux.net/~prahal/patches/opensync/opensyncsupport_fakeidlestopthread.diff 15:56 < Jc2k> dannyK: dgollub: what synce will do is something like http://synce.svn.sf.net/svnroot/synce/trunk/usb-rndis-ng/data/hal/20-usb-pda.fdi 15:57 < dgollub> Jc2k: i guess this looks nice beside it's a simple callout .. not a preprobe callout... dannyK what do you think? 15:57 < Jc2k> the script will start something we havent named yet, which among other things will update HAL 15:58 < Jc2k> adding the sync capability 15:58 < Jc2k> which GUIs can use 16:00 < dgollub> Jc2k: the stuff which get merged is another story.. first we should focus own how to get those information inside hal.. in a sane way 16:01 < dgollub> Jc2k: but this fdi file could be even used on freebsd and solaris... (and i guess the userpsace driver as well.. if it's portable and fully based on libusb) 16:01 < dgollub> Jc2k: what do you think? 16:02 < Jc2k> dgollub: i dont know libusb, but can it create network devices? 16:02 < Jc2k> we dont have libsynce or anything like that - if we used the usermode driver there would effectively be 3 daemons involved in syncing a WM5 device... 16:03 < dgollub> Jc2k: one of the daemon takes care about the ppp ip stuff? 16:04 < Jc2k> usb-rndis-ng: establishes an RNDIS connection to the device - this manifests as an eth[0-9] or rndis[0-9] 16:04 < Jc2k> dhclient runs (the windows devices have a pseudo DHCP server on them) 16:05 < Jc2k> odccm then needs to initialise it and send keep alive data 16:05 < Jc2k> (this is shared with the older ppp devices, which dont need the rndis thingy) 16:05 < Jc2k> (its also helishly complicated and does other things i dont want to know about) 16:06 < Jc2k> (and our rra and rapi1 / rapi2 implementations depend on it) 16:06 < dgollub> Jc2k: http://www.mallorn.de/m600i.html this is also interesting ;) 16:06 < Jc2k> sync-engine is then needed 16:06 < Jc2k> that is a HTTP server 16:06 < Jc2k> it implements AirSync 16:06 < Jc2k> a wbxml messyness 16:06 < dgollub> does it atleast use libwxml2? 16:07 < dgollub> libwbxml2 .. 16:07 < Jc2k> unfortunately it is patched 16:07 < Jc2k> - upstream doesnt support namespaces 16:07 < Jc2k> attempts to upstream said patch (twice).. failed 16:07 < Jc2k> due to.. 16:07 < Jc2k> extreme project deadness? 16:08 < dgollub> i guess it's a one person project ... 16:09 < dgollub> sometimes there activity.. i also send them buildenv fixes 16:09 < azeem> Jc2k: you could get the distributions to apply those patches 16:09 < azeem> +try 16:09 < dannyK> dgollub: yes, you want a preprobe callout which get called after HAL called the internal code to add the device (and set some/most (depends on the device) properties) and before the prober get called. As the hal code look the preprobe should be blocking. Because of this the device isn't normaly in the GDL and the preprobe should be fast, because the device get not added until the preprobe returned. BTw. the timeout for preprobes is 10 sec. 16:09 < dannyK> IIRC 16:10 < Jc2k> sync-engine also has some kind of buffer which i dont understand which (i think) is designed to work around for opensync 16:10 < dgollub> regarding the http server.. libsyncml provides also one.. based on libsoup - it gets started in the plugin process.. 16:10 < Jc2k> i think activesync gets uppety if it can't see the server at any point 16:10 < dgollub> dannyK: nice - thanks for all the information.. i guess this should be they way we should go - btw. what means "GDL"? ;) 16:10 < Jc2k> (it syncs in the background, to the buffer) 16:11 < dgollub> Jc2k: same for syncml-http-server plugin... 16:11 < dannyK> Global device layer IIRC. The device store that is available outside of HAL. The device is in the TDL until it get announced as ADDED 16:11 < dgollub> Jc2k: the group is running all the time and starts all the other pluginsn as soon the syncml-http-server gets incomming connection 16:12 < dgollub> dannyK: ok i see - thanks!