Re: What's objtype "data" stand for?

On Tuesday 15 April 2008 10:38:24 Halton Huo wrote:
[...]
> My understanding for 'data' concept is a special objtype, it can
> stands for 'contact', 'event', 'note', 'todo' and more like files. 

Correct - it's kind of "wildcard".

> Jijun said he ever synced file and evo2 with objtype 'data', but now
> trunk code can not. So am i missing something here?

No - thats correct for now. With 0.3x we introduced the "objtype sinks" which
allows complete seperation of the object types. Unfurtonately the file-sync
can't handle right now the mix-up of object types - e.g. evo2-sync
(contact) -> file-sync (data) .. you have to create a sink "contact" even on
the file-sync right now.

I guess the first step you'll fail on doing this mixup is the discovery phase,
which ends up and checking for "same sinks" in the end of this phase.

The second issue we had in the past with file-sync with changes as "data" from
a  plugin with several object types at once, was the duplicate UID problem.
Imagine you have a plugin which stores contacts and events - and there is an
contact entry with UID "xyz" and an event entry with the UID "xyz". Since the
file-sync used to use the UID as filename there was a problem with storing
those entry without losing the data. But for this case there are "duplicate"
function for entries, which will change the UID of the entry with the same
UID (it will append "-dup" to the UID). Since we didn't managed to handle
this flawless in file-sync we decided to stay for time being with "forcing"
the file-sync to use seperated directories for different objtypes/sinks.

But i guess lot's of people will miss this feature. So we should try to get
this working again by time. I already tried in the past to get this working
again, but there are some further stuff to do to get this working flawless.


#1 fix conversion path for objformat-xyz to objformat "file"
   * doesn't work smoothly for all objformat right now
   * for example for objformat which contain structs with pointers
     and needs to get marshalled - e.g. gnokii-format, palm-format, ...
     It would be nice to have a conversion path which marshal those formats
     with their marshal function and dump this on disk. But since the marshal
     function could be buggy as well this isn't safe...
#2 review what the discovery phase does and make it aware of the "data"
   wildcard
#3 fix the duplicate UID problem in file-sync, by just changing the UID to
   with the duplicate function


best regards,
Daniel



-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel