[My ISP seems to be alive again, I'll try resending all the messages I
wrote yesterday. My apologies if you've already received them.]
Frederik Elwert wrote:
Hi,
Hello Frederik, sorry for taking my time...
Does the D-Bus server get started on login? Or is it just started the
first time a client requests it?
Currently it is only started on demand. This is good for startup time
(power on to usable desktop), an important feature in Moblin, so we have
to be careful not to slow down the startup.
That is a good point. But for automated syncs, I think some kind of
running process is required. Maybe one should at least start the D-Bus
server on login only if automated syncs are on, and on request
otherwise.
I don't like the idea of running the server continuously... It may be
unavoidable, but I'd like to try other methods first. The needs, AFAICT,
are:
* Do things on user demand (from UI or notifications etc.)
This is easy and works already.
* Do things when remote data changes
This we can't really do, so syncing at regular intervals sounds best.
There has to be a better way to do this than running all the time (if
the other requirements don't force us to do it anyway)
* Do things when local data changes
This isn't a must-have feature (syncing at regular intervals is
acceptable), but would be nice. I assume we'd solve this for EDS
sources first:
The EDS client could be syncevo-dbus-server, a tiny
syncevo-eds-watcher, or another app: at least in Moblin we have other
EDS users (the people panel) running already, maybe we could have the
people panel start syncs?
Are delayed processes possible in the Moblin session? I think older
versions of GNOME had the possibility to start some processes after the
more important desktop related thinks were loaded. But I don‘t know if
this is possible today (if not via a hackish "sleep 30;
syncevo-dbus-server" wrapper).
This is an implementation detail that is almost certainly already solved
(considering my netbook boots in ~10 seconds)...
What about inotify?
Yes, that works. But I have heard mixed opinions about it, so I'm not
entirely sure how well it really works.
I think Rhythmbox does use it to keep the library up to date, and
nautilus also makes use of it, as does Tracker. So I think it should
work, but I’m no expert on this field.
inotify does work nowadays but isn't EDS the correct way to handle EDS
sources?
But to come back to the D-Bus API: I am currently trying to port Genesis
over to that API. Could somebody help me with understanding the API?
Jussi would be the prime candidate for that, but he is on vacation at
least this and next week. Let me try to help out.
I’m on vacation next week, too. So maybe I’ll pause working on it until
I’m back.
What I think I understand so far is:
1. The client starts a Sync with StartSync(). (I didn’t manage to
call it with an empty array for a full sync, so I read the modes
per source from the config and pushed this to the method call.)
If you can you file a bug on that, that would be great.
2. The clients registers a handler for the Progress signal. I think
I don’t need all the details here, so I simply wait for
success/failure notices? Could someone please tell me, what the
type values mean and what extra values are passed?
The values are a direct copy of the Synthesis progress events, using the
same integer codes and parameters as inside the Synthesis C/C++ SDK. The
definitions are in libsynthesis src/sysync_SDK/Sources/engine_defs.h.
Clearly this is not useful for a Python D-Bus client, but we weren't
sure about how this could be abstracted in D-Bus. We might have to
duplicate the whole set of progress events and document them as part of
our D-Bus API.
I think the only issue is documentation. Once you know where to find it,
one can well work with it. NetworkManager also sends it status as enum
values, which one has to copy to any python program as well.
Using raw synthesis values isn't a very clean solution, but I don't see
us getting totally rid of it in the near future.
Regarding end of sync, sync_progress_cb() checks for PEV_SYNCEND.
That should be sufficient for the moment. :-)
24 (PEV_SYNCEND): sync for a source ended
16 (PEV_SESSIONEND): whole sync session ended
-1: EvolutionSyncClient.sync() returned
There are some problems with the current progress implementation wrt to
future requirements... Most importantly the events should be session
specific (possibly with a new session being a new dbus object), and some
of the progress logic should be in the server side.
So expect this to change as well.
3. Once the sync completed, I get the details by calling
GetSyncReports(). But what do I actually get? What do the values
mean?
This is intended to change. My proposal in another email in this thread
was to use a flat key/value hash with special encoding of the keys
instead.
Ok, then I’d wait until this has finalised.
Agree with Patrick, plus the hashtable should probably be returned on a
SyncSessionEnd signal because most who subscribe to that signal want it
anyway.
-Jussi
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
