Hi<br><br><div><span class="gmail_quote">On 11/26/07, <b class="gmail_sendername">Martin Owens</b> <<a href="mailto:doctormo@gmail.com">doctormo@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hello Everyone,<br><br>It'd time to site down and talk about the kind of information that's<br>required to do syncing; the kinds of features and what needs to be<br>done in order to enable them all effectively.<br>
<br>The plan is for all sync enabled devices to identify themselves in<br>their fdi files as such:<br><br><append key="info.capabilities" type="strlist">sync</append><br><br>But we also need to know what to use to sync with this device:
<br><br><merge key="sync.engine" type="string">opensync</merge><br><merge key="sync.plugin" type="string">barry</merge></blockquote><div><br>I have a similar FDI for SynCE (Windows Mobile support). One question I have is, does the HAL entry appear as soon as anything at all is known about the device, or only when it is ready to be sync'd? My prototype FDI for SynCE actually appears in the GUI a little too soon, before the network endpoint of the device is configured... Perhaps in the SynCE case I can create an entire entry just for the sync "endpoint" when the device is fully configured, as a child of the rndis_host driver entry....
<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">This information however is too specific to go into HAL it's self so I<br>
propose to keep these outside packaged up in barry (in this case) and<br>putting them into 20thirdparty when installed.</blockquote><div><br>Is there any magic in autotools for this, or can I rely on the assumption that the 20thirdparty folder will be consistent in its location?
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">We also need to make sure that any devices which identify themselves<br>as syncing devices can provide a unique id, this is so when two phones
<br>or pda's of the same kind are plugged in, user software (conduit)<br>doesn't confuse the two. these are shown here for example, they're<br>going to be merged by a callout python script:<br><br><merge key="
sync.serial" type="string">67cf4023</merge><br><merge key="sync.description" type="string">RIM 8100 Series Colour<br>GPRS Handheld</merge></blockquote><div><br>Is it worth having an icon property? Is that an appropriate use of HAL?
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">It also allows us to keep track of who on the system 'owns' a specific
<br>mobile phone, and deal with passwords where required. Blackberries<br>have such a password feature, once the blackberry device has a unique<br>id, and that unique id has been paired up with a user it's a short<br>
step to using that users keyring (using appropriate authorisation)<br><br>Weather these extra features appear as an addon or a user daemon I'm<br>not sure yet so I would appreciate any and all advice on the format<br>
presented here.</blockquote><div><br>I really like the automatic unlocking of the device idea.. This is something that would help SynCE too, and is useful outside of the sync area... <br></div><br>Thanks for your time<br>
<br>John<br></div><br>