> The only real problem i'm aware of is that support for pre-WM5 devices > is limited to say the least, i understand none of the developers have > these devices, but again, i offer my support in this area in away way i > can. >
Depends on your point of view, and for this point out a distinction that I always make in my own little world, that of _connection_ and _syncing_. Pre WM5 devices connect just fine, using any kind of dccm you like. In fact for multiple device support pre WM5 is your only (apparently) tried and tested option. As far as PIM syncing is concerned, I'm still happily going with the old multisync on my WM2003 using librra. Obviously this isn't a long term option, and I'd love to play with sync-engine, but it definitely still works. > > Rather a general "what needs to be done" list. Please do reply with > > specifics! I suppose I'm suggesting we put in a freeze now and > > concentrate on bugs, for the release. > > The following things come to mind: > - Ease of use: as it is right now, synce isn't the most userfriendly > thing out there, improving the documentation here would improve the > situation alot. And we're developers, I dread to think what it must be like for anyone else ! Actually I remember when I first arrived in synce world, it was actually slightly more straight forward with my WM2003 because it was a slightly more mature system and the docs were still relevant. A lot of the current confusion is I believe due to there being no current guidelines on just what you need for a particular device. > - As i understand it, several things still require elevated rights, it > would be best if this could be avoided/reduced? Ignore this if this is > already done ;) The only thing I am aware of that requires elevated rights is the *dccm for WM5, which requires a reserved IP port, 990, therefore odccm runs as root. vdccm became suid when it supported WM5, and drops root priviledges when it doesn't need them, but this is not as nice IMHO. > > > Further goals > > ============= > > > > After 0.11 there will be some other features and fixes that will be > > worth investing time in. Two I can think of now are: > > > > * Simplifying the installation process, significantly. > > * Removing the libwbxml dependency. > > What are the current pitfalls in installation *EXCEPT* the > documentation? If feasable, why not do this now? > Having put a lot more thought into hal-dccm, I think it may make at least the connection side a lot simpler. You'll install the package and it will just work, particularly since for preWM5 synce-serial will basically have to become part of the dccm setup. > > If you have any other ideas, please state them here. If the idea has not > > previously been aired, please give some information about it. > > > > Other talking points > > ==================== > > > > vdccm: It seems to me that the only advantage of vdccm is its multiple > > device support. Therefore, I am suggesting dropping vdccm as a proper > > SynCE module. I'm not saying it should be deleted from SVN, but just > > left out of releases. Thoughts? > > The current state, where there is dccm (that's depricated iirc?), vdccm > and odccm does add to the confusion, going ahead with only one of them > makes sense. > I've probably just depressed you mentioning hal-dccm then :) Yes there are too many. dccm is deprecated and there is no point in using it ever, vdccm can be dropped straight in its place. If the debian packages weren't so old we probably wouldn't ever see it. 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 SynCE-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/synce-devel
