« Return to Thread: [RFC] Plugin specifc capabilities II
Re: [RFC] Plugin specifc capabilities II
by Daniel Gollub-2
::
Rate this Message:
On Wednesday 01 April 2009 01:52:49 pm Patrick Ohly wrote:
[...]
> > > You said elsewhere that this "config" parameter is "free defineable
> > > config strings which get set in the plugin config in the section about
> > > format configuration (e.g. <Resource><Formats>). This part of the
> > > plugin config can be set during the discover phase()."
> > >
> > > If it is "free defineable" (which I take as "defined by the conversion
> > > function" as the user of the data), how can anyone else fill in
> > > meaningful data? The sync UI wouldn't know the format, nor would the
> > > sync plugin that discovers a device.
> >
> > Some sync plugins do.
>
> ... but they have to agree with the format plugin on the content of the
> config. Therefore the config format has to be defined for each format
> type, otherwise we could end up with a situation where a config A for
> format AF is passed to a format plugin which can deal with AF, but only
> config B.
Right.
>
> > > A
> > > merger/demerger which only knows about the common internal format
> > > cannot do anything with that information.
> >
> > Right - it cannot deal directly deal with it. Some translation would be
> > required.
>
> Which might not be possible.
Since there would be the possibility to write sync plugin specific merger
functions i don't see the problem to handle the translation to various common
formats at the same time.
>
> > > You would have to write a merger/demerger for every "foreign" format
> >
> > Right. But so far i see no possibility to avoid this. Since the merging
> > and demerging only can be done if the those entry is in the
> > "forgein"/"common" fomrat - and not in the native format [1].
> >
> > I fully agree that it would be easier and more helpful if their would be
> > a possibility to merge/demerge if the format would stay in the "native"
> > format.
> >
> > But currently i'm not seeing how this could be done without dataloss. I
> > revisit this again - maybe i missed something...
> >
> > Do you have any idea how merge/demerge in the "native" format would be
> > possible without dataloss?
> > Do you have any other better proposal?
>
> Drop the separate merger/demerger concept. Move that functionality into
> the format conversion.
Ok - interesting idea.
>
> When converting towards OpenSync, the format plugin works with an item
> in the "foreign", limited format, a capabilities description that
> describes the format used by the peer, and a complete item in the
> internal format. The result is an updated internal item with information
> from the peer mixed in, or a complete copy of the incoming item when
> there is no internal item yet.
>
> When sending towards a peer, the format plugin only needs to pick
> properties from the internal item according to the peers capabilities.
> "Only read what you need" looks more natural to me than the current
> concept of "strip an item, then convert the stripped down version". The
> additional advantage is that this conversion has full access to all
> available information, which may be an advantage when going beyond a
> static capabilities-based conversion towards a scripted one which also
> uses dynamic configuration.[...]
Sounds fine to me. I try to prepare a Proof of Concept implementation.
Unfortunately this would require again changes on all format plugins which
have converter. But if this really works out, then this is definitely worth to
delay 0.39 for one more day.
Best Regards,
Daniel
------------------------------------------------------------------------------
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel
[...]
> > > You said elsewhere that this "config" parameter is "free defineable
> > > config strings which get set in the plugin config in the section about
> > > format configuration (e.g. <Resource><Formats>). This part of the
> > > plugin config can be set during the discover phase()."
> > >
> > > If it is "free defineable" (which I take as "defined by the conversion
> > > function" as the user of the data), how can anyone else fill in
> > > meaningful data? The sync UI wouldn't know the format, nor would the
> > > sync plugin that discovers a device.
> >
> > Some sync plugins do.
>
> ... but they have to agree with the format plugin on the content of the
> config. Therefore the config format has to be defined for each format
> type, otherwise we could end up with a situation where a config A for
> format AF is passed to a format plugin which can deal with AF, but only
> config B.
Right.
>
> > > A
> > > merger/demerger which only knows about the common internal format
> > > cannot do anything with that information.
> >
> > Right - it cannot deal directly deal with it. Some translation would be
> > required.
>
> Which might not be possible.
Since there would be the possibility to write sync plugin specific merger
functions i don't see the problem to handle the translation to various common
formats at the same time.
>
> > > You would have to write a merger/demerger for every "foreign" format
> >
> > Right. But so far i see no possibility to avoid this. Since the merging
> > and demerging only can be done if the those entry is in the
> > "forgein"/"common" fomrat - and not in the native format [1].
> >
> > I fully agree that it would be easier and more helpful if their would be
> > a possibility to merge/demerge if the format would stay in the "native"
> > format.
> >
> > But currently i'm not seeing how this could be done without dataloss. I
> > revisit this again - maybe i missed something...
> >
> > Do you have any idea how merge/demerge in the "native" format would be
> > possible without dataloss?
> > Do you have any other better proposal?
>
> Drop the separate merger/demerger concept. Move that functionality into
> the format conversion.
Ok - interesting idea.
>
> When converting towards OpenSync, the format plugin works with an item
> in the "foreign", limited format, a capabilities description that
> describes the format used by the peer, and a complete item in the
> internal format. The result is an updated internal item with information
> from the peer mixed in, or a complete copy of the incoming item when
> there is no internal item yet.
>
> When sending towards a peer, the format plugin only needs to pick
> properties from the internal item according to the peers capabilities.
> "Only read what you need" looks more natural to me than the current
> concept of "strip an item, then convert the stripped down version". The
> additional advantage is that this conversion has full access to all
> available information, which may be an advantage when going beyond a
> static capabilities-based conversion towards a scripted one which also
> uses dynamic configuration.
Sounds fine to me. I try to prepare a Proof of Concept implementation.
Unfortunately this would require again changes on all format plugins which
have converter. But if this really works out, then this is definitely worth to
delay 0.39 for one more day.
Best Regards,
Daniel
------------------------------------------------------------------------------
_______________________________________________
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 |
