On Fri, 2010-06-11 at 04:22 +0100, Zhu, Yongsheng wrote:
> Yeah, this idea is good to me and I think it's very useful because we support
> many backends, which give
> us the power to access different kinds of data storage.
>
> Some questions or concerns here:
> 1.
> > --print-items shows all existing items using one line per item using
> > the format "<luid>: <short description>".
> It is good enough to show all items. But what if we want to see a full
> description of one item?
> Is it possible to add an option like this "--print-item <config> <source>
> <luid>?
What would be a long description of an item in this case? Is exporting
it completely to stdout perhaps sufficient? That already works with
--export - <config> <source> <luid>
Speaking of description, there's a problem implementing this. My
intention was to use the same code which also runs as part of logging
add/update operations during a sync. This code reads certain fields from
the Synthesis field list of the item (SUMMARY of event/task, FN/N of
contact, first line of note).
But during --list, there is no Synthesis engine active and if there was,
the APIs for creating and parsing an item are missing. So I fear that
implementing the ": <short description>" part will have to wait.
> 2.
> > syncevolution [--delimiter <string>] --export <dir>|<file>|- <config>
> > <source>
> > [<luid> ...]
> > syncevolution [--delimiter <string>|none] --import <dir>|<file>|- <config>
> > <source>
> We only support import from or export to a file/directory though file
> backend, do we?
No. Any backend that supports the SyncSourceRaw interface will work. In
practice that covers all which read/write data in a serialized format
(Evolution, file backend, Akonadi, XMLRPC, Maemo) but not the sqlite
example.
For other backends we run into the same issue as with the description:
we need to parse the on-disk format first before we can add the parsed
item to the bacckend.
Long term we can do that, and perhaps even more: add options which
specify the "flavor" of the item ("vCard from Nokia N85") and go through
the same processing as during a normal sync, instead of dumping the item
directly into the backend.
> If no, how to specific what backend to be used for the items in the file?
The backend is not involved in reading items from the dir/file/-. That's
done by the command line tool. There's a slight chicken-and-egg problem
here in that splitting one file into items depends on the data items and
thus is backend specific. The "--delimiter" allows us to do the
splitting with simple text search/replace, as long as there is a
delimiter which does not appear in data items. I've updated the USAGE
section for this:
--export writes all items in the source or all items whose <luid> is
given into a directory if the --export parameter exists and is a
directory. The <luid> of each item is used as file name. Otherwise it
creates a new file under that name and writes the selected items
separated by the chosen delimiter string. stdout can be selected with
a dash.
The default delimiter are two newline characters for a blank line. This
works for vCard 3.0 and iCalendar 2.0, which never contain blank lines.
Because items may or may not end in a newline, as a special case the
initial newline of a delimiter is skipped if the item ends in a newline.
--import adds all items found in the directory or input file to the
source. When reading from a directory, each file is treated as one
item. Otherwise the input is split at the chosen delimiter. "none" as
delimiter disables splitting of the input.
> 3.
> Another thing is that what if we want to delete an item?
> A possible solution is to use a '--update' option with an empty item to
> replace the existing one.
> But I think a warning is needed to notify users.
This is indeed an obvious gap in the proposal. I suggest to add a
dedicated --delete operation.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
