Re: [trunk] [API] dropped osync_plugin_info_get_configdir (#1083)

On Wed, Apr 01, 2009 at 02:02:50AM +0200, Daniel Gollub wrote:
> > The Barry plugin relies on this function to store its cache and ID map.
> > These are just simple text files at the moment:  the cache is a list of
> > known record ID's in the Blackberry, and the idmap is a map of Blackberry
> > record ID's to opensync ID's (key/value).
>
> Whats the purpose of those IDs?
> By record you mean the entry/change IDs?

The record IDs are just numbers that the Blackberry uses to reference
a contact or a calendar item.  They are not guaranteed to be unique, but
they almost always are, and Barry is careful to maintain that
pseudo-uniqueness.


> Why not use the native Mapping Table and just use the OSyncChange UID?
> Is it due to the problem that if you commit
> new entries to the BB, the BB creates it's own ID and not using the original
> UID reported by OpenSync? If so - there is a way to "workaround" this -
> without the need to have your own mapping table. Commit your change - retrieve
> the assigned new ID from the BB, and update the OSyncChange with BB's mapping
> ID. (But yeah - wild guess - i should check your code ;))

That sounds promising.  A lot of this code is just ported from the 0.22
plugin, where I either did things simply for implementation speed, or
just didn't realize the API existed.  I decided back then to keep BB and
opensync ID's strictly separate.

I'll do some more research on OSyncChange UID.  I was under the impression
that opensync could handle alphanumeric ID's, while the BB can only do numeric.

As for adding new records via Barry, we generate the ID, so that's not a
problem.  I was more concerned with preserving the existing ID's from
BB-added records.

Time to study the API some more! :-)



> We have this OSyncStateDB (format OSyncAnchor) which is since yesterday also a
> key=value interface. In case those are independent of changes/entries.

Once an ID is mapped, it stays mapped until the record is deleted.  So if I
understand correctly, this StateDB would work for me.


Let me do some more research before I waste too much of your time. :-)

- Chris


------------------------------------------------------------------------------
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel