On Thu, 2009-07-23 at 21:26 +0100, Jussi Kukkonen wrote:
> Patrick Ohly wrote:
> See my comments on your mail below this.
>
>
> 1 Minor DBus api improvements (lessons learned in the last six months)
> - Fix some remaining bugs (mostly get the sync reports out properly)
> - make sure we are ready for automatic syncs (see 3 & 4)
> - This is a must have, it's just been more difficult than
> I expected. I'll follow up with another mail on this.
> - Question: Can we get data on local database contents?
In terms of items added/updated/deleted? Yes, that is possible.
"syncevolution --status" already shows that in addition to the changes
made to the content. It has to be requested explicitly because it
requires database accesses.
> 4 handle rejections / conflicts in the UI
> - ideally the problematic data item would be shown to the user and
> there
> would be a way "undo" a wrong conflict resolution or fix the
> rejection reason (maybe by opening the item in
> Contacts/Evolution/whatever)
> - Question: how difficult is it to get the problem "item" from EDS
> based on the info we have?
Getting the item from EDS is possible, but displaying and merging it
will be difficult and backend-dependent, at least if we extract data in
the native format of the backend. For example, vCard in Evolution is
different from vCard in KDE (assuming for a second that someone writes a
KDE backend).
Even if we assume that we know that the backend is EDS, we'd still need
an Evolution dialog for showing and merging it. We might have something
in Evolution which even does that for contacts, but I'm not sure whether
it is available via an API, it looks ugly, and is not in Moblin. Doesn't
work work for calenders.
Instead of trying to solve this on a case-by-case basis for backends, I
think it would be easier to write a general purpose Synthesis field list
display and editor. "Easier" is of course relative. This is still a huge
amount of work.
Just displaying the two items without allowing to merge won't cut it
either because (ignoring software failures) the conflict was caused by
the user adding data in two places, so both items have valuable data.
> 5 implement automatic syncing
> - sync without user interaction at interval
> - sync when local changes happen, if possible
> - libnotify notifications on sync progress/success/failure
> (no notifications when sync ui is visible?)
> - Ideally the notifier would know when a UI is open and would not
> start automatic syncs then
> - I have no idea yet where and how this should be implemented...
I think automatic syncing should be part of the core logic. Otherwise we
end up a) with a more complex D-Bus API (notifications about item
changes, which duplicates existing functionality in EDS) and b)
reimplementing the "automatic sync" feature in every frontend.
The remark about libnotify and not using it when a GUI is active is
indeed a good point. I'm a bit undecided about how much information we
should send to the user that way. Just the final sync report and fatal
error messages? In that case we might as well leave this feature enabled
(or configurable, some users might want it off) independent of a running
UI.
> > The first one is an implementation detail. The C++ SyncReport class
> > covers basically everything which can be said about a sync session,
> > ranging from statistics to success/failure information. New information
> > may get added, so we need a backwards-compatible way of sending it over
> > D-Bus.
>
> Yes, it makes sense to make the Report a Hashtable something similar
> that can contain data that may change (or at least grow) in new
> versions. The reason this isn't done yet, is that I had trouble making
> an API that would both have sane function signatures (not too many
> nested data structures) and that would not require multiple calls for
> common actions...
Can't we just use a string->string hash like the current status.ini?
start = 1248183051, 2009-07-21 15:07:51 +0200
end = 1248183055, 2009-07-21 15:07:55 +0200
status = 200
source-vcard30-mode = two-way
source-vcard30-first = false
source-vcard30-resume = false
source-vcard30-status = 0
source-vcard30-backup-before = 0
source-vcard30-backup-after = 0
This will require a bit of parsing to extract all information (list all
sources) but in other situations the hash can be used directly (what's
the overall status and status of source vcard30?).
> > I think the difference between "actively doing something" and "waiting"
> > is relevant. A sync session can hang for a long time without any
> > progress update when a HTTP server or the network are slow. As I said in
> > "UI needs a progress
> > spinner" (http://bugzilla.moblin.org/show_bug.cgi?id=2229), the spinner
> > should only be active when the client is waiting, not when it is doing
> > something. If we want to be really fancy, we could spin a "waiting for
> > IO" animation while waiting and something else while processing (turning
> > gears?).
>
> I'm not sure about this. As a user I just want to know things are
> happening,
Exactly ;-) A spinner which never changes while the sync runs does not
indicate that the backend is still alive: the backend might have crashed
and all that we see is the GUI twiddling its thumbs.
> I'm not really interested in what detail is going on (to that
> level of detail)... I imagine it would be enough to add a "waiting"
> state to the Progress signal we already have?
The Synthesis events might already be enough, but I'm not sure myself.
> > In addition to reading and presenting information, there is also a
> > variety of operations that controllers need to do:
> > * start a session
> > * create and update configurations
> > * browse and restore data from the backups
> > * parse and execute command line parameters (so that the
> > "syncevolution" command line tool really is just a main()
> > function with some D-Bus code, unless it is compiled in the
> > traditional "call local class" mode)
>
> This last point may be tricky (I really don't know), the original api
> design was based on "what am I going to need for a simple UI", there may
> be some more complex corner cases hidden in there -- syncevolution is a
> pretty versatile beast...
I think it could be made pretty simple. In the client:
- send whole argv
- listen for output and print it
- return with final status
In the server:
- accept argv, hand it to SyncEvolutionCmdline
- replace printing to stdout/cout with our own output stream
- redirect stdout like already done for stderr
- broadcast output to clients via D-Bus
Not using stdout/cout for user-visible output has multiple advantages:
- the replacement stream can be logged (not done right now)
- it allows filtering of the normal stdout (g_debug()!)
> On one hand it would ensure the api is complete, but it might still
> not be worth the trouble -- especially if you plan to keep the non-dbus
> mode as well. We'll see.
If there is a D-Bus server, then running the current command line tool
is not desirable, because we might end up with two sync sessions
accessing the same data at the same time.
--
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
