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.