> > * Mess with wbxml. I have some basic pure python wbxml that we could > > think about using, but i'm almost ashamed to admit it right now - not > > really had time for it and code is a messy port of some PHP > > Is that based on the PHP-based Exchange/Activesync server/application > that I was linked to from #synce? I definitely think this is important, > but perhaps not enough to work on before 0.11..
z-push is the PHP app of which I speak. > > > * HAL integration - a HAL callout that: > > * dhcp-ifies a device > > * starts odccm with the ips that dhcp sorted out (if not running) > > * starts sync-engine (if not running) > > > > If this doesn't make it for 0.11, any objections to a 0.12 closely > > following when these bits are ready? > > I prefer the sound of closely after 0.11. I remember reading the HAL > guide on a bus a while ago -- what you speak of wouldn't be that hard, > would it? Right. This is theoretically quite easy. It would likely explode if a user plugged 2 devices in at once, but if we don't care about that for 0.12 then fairy nuff. > > > * Simplifying the installation process, significantly. > > > > Helping main distros get everything packaged and the hal callout i > > mentioned should do this. > > Mmm, good point -- the automation could easily go in the packaging. This > would mean that it would be more seamless than if we tried to generalise > the automation across all distros. However, this would involve having a > super packaging-push -- this is a good thing however. What would be > needed -- Debian, Ubuntu, Fedora, openSUSE, originally I think. And Gentoo needs its ebuilds. Gentoo and Ubuntu are getting the most users in #synce right now. > > > I'd like to see odccm be per device if its possible. And use HAL to > > close each odccm when its own device is removed.. Any device > > properties should be stashed in HAL rather than apps having to talk to > > odccm. It seems a large chunk of odccm is boilerplate :-( > > Personally I don't really see the point in supporting multiple devices > in odccm -- about 1 in 100 users need it, and I can't imagine it taking > next-to-no time to implement too. Yay. I like that answer. > > > In terms of supporting device passwords, blackberry also works in a > > similar way and i'm pushing for some freedesktop-ish hook for storing > > passwords in the keyring so that they can be automatically unlocked - > > where we share as much as possible with barry (which is effectively > > the synce of blackberry) > > Can you expand on this please? What keyring? Blackberry works in what > similar way -- is this having the password-entry on the device? Right. The unlocking of password protected ness. The same way in which you plug in a LUKS encrypted volume and are prompted for a password, we will prompt you for a password and optionally story it in the GNOME/KDE keyring (does KDE have one?) and then auto-unlock it in future. > > There is no "modern" way to sync 2003 devices. You seem to have to use > > ancient programs like a pre-opensync version of multisync. About 1 in > > 5 #synce requests is WM2003 related... That was a guess. Enough for it > > to bother me that we don't offer support any more :P > > So you think we should stop releasing specific WM2003 modules too > (synce-serial)? I was proposing we pray to jagow for sync-engine/2003 goodness... > > > I presume vdcccm won't support WM6? It also doesn't work with > > sync-engine. Unfortunately dropping it hurts KDE users, who often ask > > about RAKI. I have no idea what exactly that is, but seems not to work > > with odccm. Yet. I am strongly in favor of having just one *dccm. > > Either RAKI support in odccm or another standalone proggy, or vdccm > > needs to be extended for WM6 and needs to be made to work with > > sync-engine? > > No I don't think vdccm does work with WM6. You bring up RAKI, but > remember that isn't a proper SynCE module now -- it was not released > with 0.10.0. > Ahh good point. RAKI was mentioned a lot when I tried to get people running odccm in #synce is all. I'll make a note that is deprecated... John ------------------------------------------------------------------------- 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
