On Thu, 2007-12-06 at 21:32 +0000, John Carr wrote: > Hi Mark > > Sorry for not replying sooner, been locked in conversation with the > ubuntu guy and opensync peoples about... HAL :-) > > > Really !? My first thought is, How Odd. Actually I remember someone in > > the past insinuating something like that, just before I made odccm's ip > > setup configurable, but I thought I was misunderstanding. > > > > I suppose that would work though, *dccm would pick up the new interface > > and dhclient it rather than assign a static address. But then how does > > the device know what addresses it can use to avoid clashes ? > > Yes, very odd indeed! I have no idea how it would cope with multiple > addresses at all. >
Ok, we'll pend that thought..... > > Cool, yep I'm in Surrey, I'll definitely consider that. For now could > > you send an ifconfig of an interface, and anything else you think may > > help my understanding ? > > I will get you output from my WM6 device as soon as my brain is awake > - right now i'm falling asleep and I have another 2 emails to write... > Hmm yes, must remember to sleep myself. > > I'm coming around to the HAL idea actually, but I'm not that aware of > > how much you can do. Would it go something like this. > > > > 1) Register a device type with HAL, so when a WM is connected it starts > > a *dccm. > > We provide an FDI that tells HAL to start a script when a device using > the rndis_host or ipaq driver is detected Said script initiates dccm > as below > Ok, that's cool, gives me another place for research, thanks. > > 1) How does *dccm know what ip configurations it can use, and which may > > already be in use by other devices ? We no longer have centralised data > > in a single process. > > No idea - even with one *dccm its weird as the device has its own DHCP > server.. We can at least publish the ips and what not in HAL so that > other interested parties know what to connect to? > Probably the funkiest thing here would be getting a rapi connection. I guess the best think would be for *dccm to connect to dbus and provide a call to obtain a socket, as odccm does now. The dbus address for this could then be published in hal, cool. So what do you think of hal-dccm, or dccm-hal ? I know i know, breaking with synce tradition :) > > 2) How would we send a 'device connected' signal to the likes of > > trayicon and raki ? Multiple processes couldn't bind to a single dbus > > address, can HAL actively send arbitrary events ? > > HAL sends new device events. You can also get a "new capability" event > when you modify the "info.capabilities" property. Any data you > currently get from odccm over dbus i think we would get over HAL > instead. > > A HAL device also has a path of its own, not unlike how odccm behaves. > Ah yes, of course, just watch hal for connection events with the right properties, odccm does that, must be getting late. And of course post all the other device info as properties. Ok, I'm in for this, just need to figure out the fdi stuff, work out how to do legacy devices with ppp, and clone myself :) Mark ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ SynCE-Devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/synce-devel
