« Return to Thread: [RFC] Plugin specifc capabilities II
Re: [RFC] Plugin specifc capabilities II
by Daniel Gollub-3
::
Rate this Message:
On Thursday 02 April 2009 01:11:06 am Graham Cobb wrote:
[...]
> I am away on holiday and will not have a chance to review this in any
> detail until after Easter. I did glance at the Wiki pages and I am not
> sure if this addresses the problems I found while trying to create the
> capabilities for GPE: the merger process seems to need to be different for
> data being sent to the device from OpenSYnc and data being received from
> the device and sent to OpenSync. In particular, there is data which should
> be included in the update sent to the device but which should not be
> trusted when it is received from the device. This seems to mean that there
> are three states neded for each attribute: supported, untrusted (specify
> on send, ignore on receive), excluded (do not specify on send, ignore on
> receive).
Could you give me an vcard/gpe example for: untrusted and excluded scenario?
>
> The second problem was granularity: how detailed the capabilities can be
> (e.g. if the device can store a home and work address but not the various
> different types of address which can be defined using the RFC). The only
> short term API impact of this isue is that it shoud be possible to make
> the capability definition files handle more granular capabilities in the
> future without breaking the capabilities we define today. So, for example,
> the format should allow us to define today that address is untrusted but
> tomorrow we may extend the merger capabilities to specify that up to two
> addresses are supported.
I hope we address this with a SyncML like capabilities schema - vcard-Based-
capabilities description:
<Caps objtype="contact">
<Cap>
<DisplayName>Name</DisplayName>
<MaxOccurs>1</MaxOccurs>
<Max>64</Max>
<Min>1</Min>
<Name>N</Name>
<Parameter>
<Name>ENCODING</Name>
<Type>string</Type>
<ValEnum>ACSII</ValEnum>
<ValEnum>UTF-8</ValEnum>
<ValEnum>UTF-16</ValEnum>
</Parameter>
<Type>string</Type>
</Cap>
<Cap>
<DisplayName>Telephone</DisplayName>
<MaxOccurs>3</MaxOccurs>
<Max>128</Max>
<Min>1</Min>
<Name>TEL</Name>
<Parameter>
<Name>ENCODING</Name>
<Type>string</Type>
<ValEnum>ASCII</ValEnum>
</Parameter>
<Parameter>
<Name>TYPE</Name>
<Type>string</Type>
<ValEnum>HOME</ValEnum>
<ValEnum>WORK</ValEnum>
<ValEnum>CELL</ValEnum>
<ValEnum>FAX</ValEnum>
<ValEnum>CELL,WORK</ValEnum>
<ValEnum>FAX,WORK</ValEnum>
<ValEnum>PREFERED</ValEnum>
</Parameter>
<Type>string</Type>
</Cap>
</Caps>
(This XML dump will get assembled via an osync_capabilit(ies|
y)_get/set/add_xxx() interface - in the discover function of a sync-plugin)
Best Regards,
Daniel
--
Daniel Gollub Geschaeftsfuehrer: Ralph Dehner
FOSS Developer Unternehmenssitz: Vohburg
B1 Systems GmbH Amtsgericht: Ingolstadt
Mobil: +49-(0)-160 47 73 970 Handelsregister: HRB 3537
EMail: gollub@... http://www.b1-systems.de
Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg
http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D
------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel
[...]
> I am away on holiday and will not have a chance to review this in any
> detail until after Easter. I did glance at the Wiki pages and I am not
> sure if this addresses the problems I found while trying to create the
> capabilities for GPE: the merger process seems to need to be different for
> data being sent to the device from OpenSYnc and data being received from
> the device and sent to OpenSync. In particular, there is data which should
> be included in the update sent to the device but which should not be
> trusted when it is received from the device. This seems to mean that there
> are three states neded for each attribute: supported, untrusted (specify
> on send, ignore on receive), excluded (do not specify on send, ignore on
> receive).
Could you give me an vcard/gpe example for: untrusted and excluded scenario?
>
> The second problem was granularity: how detailed the capabilities can be
> (e.g. if the device can store a home and work address but not the various
> different types of address which can be defined using the RFC). The only
> short term API impact of this isue is that it shoud be possible to make
> the capability definition files handle more granular capabilities in the
> future without breaking the capabilities we define today. So, for example,
> the format should allow us to define today that address is untrusted but
> tomorrow we may extend the merger capabilities to specify that up to two
> addresses are supported.
I hope we address this with a SyncML like capabilities schema - vcard-Based-
capabilities description:
<Caps objtype="contact">
<Cap>
<DisplayName>Name</DisplayName>
<MaxOccurs>1</MaxOccurs>
<Max>64</Max>
<Min>1</Min>
<Name>N</Name>
<Parameter>
<Name>ENCODING</Name>
<Type>string</Type>
<ValEnum>ACSII</ValEnum>
<ValEnum>UTF-8</ValEnum>
<ValEnum>UTF-16</ValEnum>
</Parameter>
<Type>string</Type>
</Cap>
<Cap>
<DisplayName>Telephone</DisplayName>
<MaxOccurs>3</MaxOccurs>
<Max>128</Max>
<Min>1</Min>
<Name>TEL</Name>
<Parameter>
<Name>ENCODING</Name>
<Type>string</Type>
<ValEnum>ASCII</ValEnum>
</Parameter>
<Parameter>
<Name>TYPE</Name>
<Type>string</Type>
<ValEnum>HOME</ValEnum>
<ValEnum>WORK</ValEnum>
<ValEnum>CELL</ValEnum>
<ValEnum>FAX</ValEnum>
<ValEnum>CELL,WORK</ValEnum>
<ValEnum>FAX,WORK</ValEnum>
<ValEnum>PREFERED</ValEnum>
</Parameter>
<Type>string</Type>
</Cap>
</Caps>
(This XML dump will get assembled via an osync_capabilit(ies|
y)_get/set/add_xxx() interface - in the discover function of a sync-plugin)
Best Regards,
Daniel
--
Daniel Gollub Geschaeftsfuehrer: Ralph Dehner
FOSS Developer Unternehmenssitz: Vohburg
B1 Systems GmbH Amtsgericht: Ingolstadt
Mobil: +49-(0)-160 47 73 970 Handelsregister: HRB 3537
EMail: gollub@... http://www.b1-systems.de
Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg
http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D
------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel
« Return to Thread: [RFC] Plugin specifc capabilities II
| Free embeddable forum powered by Nabble | Forum Help |
