On Wed, 2007-08-29 at 19:25 -0400, Richard Alimi wrote: > Hi Mark, > > > would use the device_name direct with odccm, or construct a full path > > for vdccm internally. If the named device is not found you get a NULL. > > We could still allow a NULL device_name to get the old behaviour. > > > > RapiConnection * rapi_connection_from_name() > > > > would then use this new libsynce function. rapi_connection_from_info() > > and stand-alone CeRapiInit could stay as is. > > > > All this is quite easy to implement, just wanted to see what any > > interested voices had to say. > > To echo what David had to say, this is great that you are continuing on with > this! > > Your suggestion above seems reasonable, but I wonder how much we would > benefit > from just hacking at the existing library and keeping full > backwards-compatibility. I like the idea of just passing the device name and > doing the conversion under the covers, but I'm wondering if we should really > keep around the old versions of the function. I worry that if we keep adding > new functions while keeping all of the old ones, it will difficult to > maintain or understand. Since no one is really hacking away at the libraries > at the current time anyways, what about creating a branch in SVN on which the > libsynce/librapi library interfaces are updated to be nice and beautiful to > work with any *dccm? On that branch, the calls to the library functions that > change from other synce components can be updated to use the new interfaces. >
I can go for that, and on a quick grep through the contents of svn trunk, I don't imagine even a new branch will be necessary. So what we would have is SynceInfo * synce_info_new(const *char device_name) where passing NULL would give the current behaviour, and a name is checked first against odccm then vdccm. rapi_connection_from_info() will be fine as is. rapi_connection_from_path() will have to be scrapped and replaced by rapi_connection_from_name(). Standalone CeRapiInit() will also be fine as is. Sound ok ? > One downside, however, is compatibility with other code that is *not* in our > SVN tree. Does anyone have an idea if there are (or how many) other projects > are making use of these libraries? > Off the top of my head, only FUR and synceFS. Quick grep, talk amongst yourselves..... Both use CeRapiInit, so should be unaffected. Mark ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ SynCE-Devel mailing list SynCE-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/synce-devel
