Re: [SyncEvolution] new command line options: import/export

On Fri, 2010-06-11 at 04:22 +0100, Zhu, Yongsheng wrote: 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. 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. 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. 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.