« Return to Thread: [RFC] Plugin specifc capabilities II
Re: [RFC] Plugin specifc capabilities II
by Patrick Ohly
::
Rate this Message:
On Tue, 2009-03-31 at 17:41 +0200, Daniel Gollub wrote:
> On Tuesday 31 March 2009 04:14:32 pm Patrick Ohly wrote:
> > In particular: how many caches are needed?
> What do you mean by "caches" in detail?
The entity where items are "cached". In other words, a set of ID+data
pairs where the ID is used to extract the data stored there earlier.
> We have OSyncArchive - which cover the API to access the database which
> archive/cache the full/entire entries of a format.
>
> CREATE TABLE tbl_archive (objtype VARCHAR(64), mappingid INTEGER, data BLOB,
> PRIMARY KEY (objtype, mappingid) )
>
> This is how the internal table looks like to store the full/entire entries.
>
> Reading this - SQL query i just realize that my previous statements were
> wrong. For each mapping there is only one "cache". Does this answer your
> question?
Not quite. What is the "mappingid"? 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?
> > > [2] http://opensync.org/wiki/trunk/features/mergerCapabilities
> >
> > Allowing arbitrary combinations of OSyncObjFormat and capabilities
> > description looks nice in theory; in practice I don't expect that there
> > will be many mergers that really support many arbitrary combinations
> > The API can be left like it is,
>
> Why API the current? Or the proposed one from [2]?
The one from [2].
> > At
> > least according to the Wiki page above, merge plugin's only work with
> > one particular format, so I suppose conversion plugins are the ones
> > which deal with two different formats.
>
> Right - this is how the current implementation looks like.
>
>
> >
> > How are conversion plugins parameterized?
>
>
>
> osync_bool conv_func(char *input, unsigned int inpsize,
> char **output, unsigned int *outpsize,
> osync_bool *free_input,
> const char *config,
> void *userdata,
> OSyncError **error)
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.
But there's a bigger disconnect between the current design and
real-world systems which use capabilities: in SyncML, capabilities are
based on the format transmitted via SyncML, for example vCard 2.1. A
merger/demerger which only knows about the common internal format cannot
do anything with that information.
You would have to write a merger/demerger for every "foreign" format and
then merging/demerging might as well be done as part of the format
conversion - except that the current APIs don't allow that.
> Do you want to add OSyncCapabilities pointer as well?
Yes, but in the current design the sync plugins don't provide that
information. They only provide capabilities for the merger/demerger.
> Two OSyncCapabilities* - for the source and destination peer?
No. Only for the less capable "foreign" format. By design the internal
format must be as capable as all formats it is converted from/into.
--
Bye, Patrick Ohly
--
Patrick.Ohly@...
http://www.estamos.de/
------------------------------------------------------------------------------
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel
> On Tuesday 31 March 2009 04:14:32 pm Patrick Ohly wrote:
> > In particular: how many caches are needed?
> What do you mean by "caches" in detail?
The entity where items are "cached". In other words, a set of ID+data
pairs where the ID is used to extract the data stored there earlier.
> We have OSyncArchive - which cover the API to access the database which
> archive/cache the full/entire entries of a format.
>
> CREATE TABLE tbl_archive (objtype VARCHAR(64), mappingid INTEGER, data BLOB,
> PRIMARY KEY (objtype, mappingid) )
>
> This is how the internal table looks like to store the full/entire entries.
>
> Reading this - SQL query i just realize that my previous statements were
> wrong. For each mapping there is only one "cache". Does this answer your
> question?
Not quite. What is the "mappingid"? 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?
> > > [2] http://opensync.org/wiki/trunk/features/mergerCapabilities
> >
> > Allowing arbitrary combinations of OSyncObjFormat and capabilities
> > description looks nice in theory; in practice I don't expect that there
> > will be many mergers that really support many arbitrary combinations
> > The API can be left like it is,
>
> Why API the current? Or the proposed one from [2]?
The one from [2].
> > At
> > least according to the Wiki page above, merge plugin's only work with
> > one particular format, so I suppose conversion plugins are the ones
> > which deal with two different formats.
>
> Right - this is how the current implementation looks like.
>
>
> >
> > How are conversion plugins parameterized?
>
>
>
> osync_bool conv_func(char *input, unsigned int inpsize,
> char **output, unsigned int *outpsize,
> osync_bool *free_input,
> const char *config,
> void *userdata,
> OSyncError **error)
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.
But there's a bigger disconnect between the current design and
real-world systems which use capabilities: in SyncML, capabilities are
based on the format transmitted via SyncML, for example vCard 2.1. A
merger/demerger which only knows about the common internal format cannot
do anything with that information.
You would have to write a merger/demerger for every "foreign" format and
then merging/demerging might as well be done as part of the format
conversion - except that the current APIs don't allow that.
> Do you want to add OSyncCapabilities pointer as well?
Yes, but in the current design the sync plugins don't provide that
information. They only provide capabilities for the merger/demerger.
> Two OSyncCapabilities* - for the source and destination peer?
No. Only for the less capable "foreign" format. By design the internal
format must be as capable as all formats it is converted from/into.
--
Bye, Patrick Ohly
--
Patrick.Ohly@...
http://www.estamos.de/
------------------------------------------------------------------------------
_______________________________________________
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 |
