Hi<br><br><div><span class="gmail_quote">On 11/26/07, <b class="gmail_sendername">Martin Owens</b> &lt;<a href="mailto:doctormo@gmail.com">doctormo@gmail.com</a>&gt; 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&#39;d time to site down and talk about the kind of information that&#39;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>&lt;append key=&quot;info.capabilities&quot; type=&quot;strlist&quot;&gt;sync&lt;/append&gt;<br><br>But we also need to know what to use to sync with this device:
<br><br>&lt;merge key=&quot;sync.engine&quot; type=&quot;string&quot;&gt;opensync&lt;/merge&gt;<br>&lt;merge key=&quot;sync.plugin&quot; type=&quot;string&quot;&gt;barry&lt;/merge&gt;</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&#39;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 &quot;endpoint&quot; 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&#39;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&#39;s of the same kind are plugged in, user software (conduit)<br>doesn&#39;t confuse the two. these are shown here for example, they&#39;re<br>going to be merged by a callout python script:<br><br>&lt;merge key=&quot;
sync.serial&quot; type=&quot;string&quot;&gt;67cf4023&lt;/merge&gt;<br>&lt;merge key=&quot;sync.description&quot; type=&quot;string&quot;&gt;RIM 8100 Series Colour<br>GPRS Handheld&lt;/merge&gt;</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 &#39;owns&#39; 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&#39;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&#39;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>