« Return to Thread: [RFC] Plugin specifc capabilities II
Re: [RFC] Plugin specifc capabilities II
by Graham Cobb-4
::
Rate this Message:
On Sunday 10 May 2009 20:58:15 Daniel Gollub 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?
One real example: until recently there was a bug in the GPE contact
processing. The N: line was received, parsed, stored and displayed to the
user perfectly correctly. However, when generating the N: line for export,
the bug dropped one of the fields! So, for example,
N:Last ; First ; Middle ; Nprefix ; Suffix
might come back as:
N:Last ; First ; Middle ; ; Suffix
So, for this software version, I wanted to configure the capabiltiies such
that OpenSync sends the N: line but ignores any received N: line because it
has been corrupted.
Another case is TYPE parameters. GPE does not support them so they get
dropped from fields which include them (e.g. phone numbers, email addresses,
etc.). Until we have a capabiltiies specification format which allows me to
specify this, I wanted to configure these fields such that they get sent to
GPE but the returned value is ignored.
These are examples of what I called "untrusted": the data should be sent to
the device but it should be ignored when received from the device. Note that
in these cases, it isn't good enough to remove them from the outbound update
completely because these are important fields that the GPE user wants to be
able to see.
The other case is not currently a problem for GPE but there (may be) some
devices which cannot handle receiving a particular field at all -- it needs
to be removed from the update before sending it to the device. This is the
way the current capabilities code works which is (presumably) desired for
some devices (and could be desired for GPE in future if a bug meant that
receiving a particular attribute caused an error).
I hope these examples clarify what I meant in these two cases, let me know if
I need to explain further.
One way to solve this problem is to have two separate capabilities files: one
for filtering outbound updates, and a separate one for filtering inbound
reports and merging.
Graham
------------------------------------------------------------------------------
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?
One real example: until recently there was a bug in the GPE contact
processing. The N: line was received, parsed, stored and displayed to the
user perfectly correctly. However, when generating the N: line for export,
the bug dropped one of the fields! So, for example,
N:Last ; First ; Middle ; Nprefix ; Suffix
might come back as:
N:Last ; First ; Middle ; ; Suffix
So, for this software version, I wanted to configure the capabiltiies such
that OpenSync sends the N: line but ignores any received N: line because it
has been corrupted.
Another case is TYPE parameters. GPE does not support them so they get
dropped from fields which include them (e.g. phone numbers, email addresses,
etc.). Until we have a capabiltiies specification format which allows me to
specify this, I wanted to configure these fields such that they get sent to
GPE but the returned value is ignored.
These are examples of what I called "untrusted": the data should be sent to
the device but it should be ignored when received from the device. Note that
in these cases, it isn't good enough to remove them from the outbound update
completely because these are important fields that the GPE user wants to be
able to see.
The other case is not currently a problem for GPE but there (may be) some
devices which cannot handle receiving a particular field at all -- it needs
to be removed from the update before sending it to the device. This is the
way the current capabilities code works which is (presumably) desired for
some devices (and could be desired for GPE in future if a bug meant that
receiving a particular attribute caused an error).
I hope these examples clarify what I meant in these two cases, let me know if
I need to explain further.
One way to solve this problem is to have two separate capabilities files: one
for filtering outbound updates, and a separate one for filtering inbound
reports and merging.
Graham
------------------------------------------------------------------------------
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 |
