On Thu, 2007-12-27 at 13:11 +0000, John Carr wrote: > On Dec 27, 2007 12:44 PM, Dr J A Gow <[EMAIL PROTECTED]> wrote: > > > > On Thu, 2007-12-27 at 12:25 +0000, John Carr wrote: > > > > > I like the idea of dbus activation, and using HAL to automatically > > > close sync-engine when the device is unplugged, but am not how the > > > device will cope if it is plugged in and the HTTP server for AirSync > > > is not responding straight away. > > > > > > > One doesn't need to close sync-engine when a device is unplugged - or > > restart it when a device is plugged in. The problem is starting it the > > first time - once it is started it can be left running throughout the > > session. I am looking at some modifications to sync-engine to allow it > > to fork itself into the background and log to a file - all that has to > > happen then (as with now) is for the user to include it in a suitable > > startup file. Thanks to a patch from Guido Diepen sync-engine will also > > now start cleanly in the absence of a running odccm and pick up the > > connection when odccm comes alive. > > > > If we make an init.d script for odccm (so it starts as root: I'll do a > > quick one for SuSE if you like and pop it in the odccm tree) and place > > the call to sync-engine in a user's startup file for whatever > > environment is chosen, then everything should work. > > > > All we need to do now is to find a way to terminate OpenSync cleanly if > > the sync-engine is not running or a device is not connected. This should > > be easy in OpenSync 0.3x but may be troublesome in the earlier releases. > > I am working on this. > > > > There are some remaining error-handling issues in sync-engine which > > require a restart of sync-engine to clear (e.g. RAPI call > > failure/timeout). Once these are cleared sync-engine should run happily > > in the background. > > > > John. > > While that would work, are we happy having 2 programs resident all the > time, even when they are not needed? I personally hardly ever care
Two programs ? Do you mean *dccm and sync-engine ? Having this split seems like a good idea to me. *dccm is solely concerned with access to the device, irrespective of whether you want file access, syncing, etc. Sync-engine is concerned with one aspect of a connected device ie. syncing. Is this what you meant ? > about syncing and would no doubt be bothered that I have these extra > programs running for the once or twice a week task of syncing. Though > I don't think they'll dent the 2gb of RAM in this machine, its still > resources being used that don't need to be. In the long run i'd only > accept this approach if we took 3 steps: Minimize memory used, > minimize any timer based activity (waking up when a device isnt even > attached is just wasting my laptops battery) and make sure that the > ports are only open on the device interfaces (vdccm was exploitable, > if we bound to a public facing interface like my wifi card i would be > very afraid). Of course these are all hypothetical and just random > brain farts... > Hal-dccm will only run when a device is connected. I agree that it would be nice to only kick off sync-engine in a similar way, but I do think it should be a user session based action, rather than a system one. Mark ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ SynCE-Devel mailing list SynCE-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/synce-devel
