« Return to Thread: [RFC] Plugin specifc capabilities II
Re: [RFC] Plugin specifc capabilities II
by Patrick Ohly
::
Rate this Message:
On Wed, 2009-04-01 at 10:33 +0200, Daniel Gollub wrote:
> On Wednesday 01 April 2009 08:51:32 am Patrick Ohly wrote:
> [...]
> > In the statement above it serves as
> > the key which is used to identify an item, together with the type. Who
> > chooses the mappingid and what is its namespace? How many instances of
> > the table above are created?
>
> long long int osync_mapping_table_get_next_id(OSyncMappingTable *table)
>
> This function gets the next free mappingid.
> I hope this answers your question?
Yes. The mappingid corresponds to the GUID in a SyncML, with a name
space that is common among all peers synchronizing against this
particular instance of OpenSync.
> > 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.
> > 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.
> > 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.
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.
> > > Do you want to add OSyncCapabilities pointer as well?
> >
> > Yes, but in the current design the sync plugins don't provide that
> > information.
>
> Which information? The capabilities? Sure they do - who else assembles the
> capabilities?
They can only provide capabilities targeted at either the merger or the
converter, but not both. In the current design they are asked to provide
information for the merger, so conversion cannot use the capabilities
provided e.g. by the SyncML protocol.
--
Best Regards
Patrick Ohly
Senior Software Engineer
Intel GmbH
Software & Solutions Group
Hermuelheimer Strasse 8a Phone: +49-2232-2090-30
50321 Bruehl Fax: +49-2232-2090-29
Germany
------------------------------------------------------------------------------
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel
> On Wednesday 01 April 2009 08:51:32 am Patrick Ohly wrote:
> [...]
> > In the statement above it serves as
> > the key which is used to identify an item, together with the type. Who
> > chooses the mappingid and what is its namespace? How many instances of
> > the table above are created?
>
> long long int osync_mapping_table_get_next_id(OSyncMappingTable *table)
>
> This function gets the next free mappingid.
> I hope this answers your question?
Yes. The mappingid corresponds to the GUID in a SyncML, with a name
space that is common among all peers synchronizing against this
particular instance of OpenSync.
> > 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.
> > 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.
> > 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.
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.
> > > Do you want to add OSyncCapabilities pointer as well?
> >
> > Yes, but in the current design the sync plugins don't provide that
> > information.
>
> Which information? The capabilities? Sure they do - who else assembles the
> capabilities?
They can only provide capabilities targeted at either the merger or the
converter, but not both. In the current design they are asked to provide
information for the merger, so conversion cannot use the capabilities
provided e.g. by the SyncML protocol.
--
Best Regards
Patrick Ohly
Senior Software Engineer
Intel GmbH
Software & Solutions Group
Hermuelheimer Strasse 8a Phone: +49-2232-2090-30
50321 Bruehl Fax: +49-2232-2090-29
Germany
------------------------------------------------------------------------------
_______________________________________________
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 |
