On Wed, 2007-11-28 at 13:44 +0000, John Carr wrote:
>         The most significant difference is an init script that gets
>         installed
>         for odccm, but if it's used with odccm 0.10.0 it'll always
>         show a fail
>         on startup, odccm has started ok but always returns failure,
>         I've fixed 
>         it in svn.
> 
> One thing i've been talking to ubuntu about (and oleavr) is triggering
> odccm from udev (or a hal callout). Then it would attach to a hal
> removal event to close itself. Any useful information about the device
> would be pushed in to HAL, rather than accessed through odccm - that
> includes information needed to connect to the device. Odccm would then
> just do keep alive. Thoughts on this would be appreciated. For
> example, i'm not really sure how that would work with multiple
> devices, although i'm not sure if odccm even supports multiple devices
> anyway. 

I thought about something like this, but not for long, too much else to
do :) As far as multiple devices with odccm, I've not tested anything,
but it's close. For ppp connections, ie pre WM5, some adjustments to
synce-serial will be needed, but odccm should deal with them after that.
For WM5, it'll only autoconfigure one interface at the moment.

> 
> 
>         I tried some funky stuff to automatically set up start/stop
>         links, but
>         upgrades require some careful planning so I disabled that. Oh
>         and of 
>         course my odccm is configured to --enable-legacy.
> 
> On that note, I think legacy should be switched on by default out of
> the box, with a --disable-legacy option instead... It won't hurt WM5/6
> users and could save support questions. 

I would tend to agree, especially now I'm confident it works.

> 
> 
>         Since we're on this, I'll throw out some ideas for
>         consideration.
>         
>         1) Some stuff in svn has out of date debian dirs, I think this
>         should
>         either be kept up to date or removed entirely, otherwise it
>         confuses the
>         situation. The deb patches may be better kept somewhere else
>         in svn.
> 
> Conduit used to have its own debian dirs, and we were told that this
> is sometimes frowned upon by packagers. So I'd vote to drop them... 
> 
> 
>         2) There are a few small items in the current deb archive
>         packages that
>         we could put into svn ie small fixes and man pages. I've done
>         some, eg
>         with liborange I think, but if anyone else has the time,
>         inclination and 
>         unserstanding to have a quick look this could be useful.
> 
> Agreed, although we maybe lacking on volunteers. We can't even muster
> a documentation effort at the moment..
>  

I think I might have a look at this now, hopefully shouldn't take too
long.

Mark


-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
SynCE-Devel mailing list
SynCE-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/synce-devel

Reply via email to