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:
> --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
Is it possible to add an option like this "--print-item <config>
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.
> syncevolution [--delimiter <string>] --export <dir>|<file>|-
> [<luid> ...]
> syncevolution [--delimiter <string>|none] --import
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
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
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
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
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.
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.