On Fri, 2010-06-11 at 07:36 +0100, Patrick Ohly wrote: > 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).
I forgot that there's also code to extract a description from local data, without using the engine. I'm using that now. > > 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. I called it "--delete-items" because I --remove was already in use and I didn't want to add an option that could too easily be mistaken with that. Full implementation is now in the "import-export" branch of git. Yongsheng, can you review it? I'll finish tagging SyncEvolution 1.0 now, then pretty soon we can open "master" for SyncEvolution 1.1 work. -- 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
