I suppose you wanted to keep this on the list, so I'm copying the list
On Tue, 2009-07-28 at 20:39 +0100, Frederik Elwert wrote:
Am Montag, den 27.07.2009, 09:13 +0200 schrieb Patrick Ohly:
> Agreed so far, except that I think the logic should be inside the D-Bus
Ok, I see. Then we should probably think about an API for automated
syncs. Just one question: Automated syncs require also some kind of
autostart. Once a user sets up, let’s say, a sync interval of 60
minutes, the syncs should run in the background right after booting the
computer (or at least after logging in).
The user has to be logged in. The user's session bus must exist for
reliable access to the EDS. There are workarounds for headless setups
(server), like running dbus-launch manually, but if we do that on a
machine where the user might log in later there's no guarantee that we
won't end up with two EDS instances.
To make it even more obvious, in some setups (laptop) the home directory
might encrypted and only become available when the user logs in.
Unfortunately, there is no "per user session" cron. For permanently
monitoring the local state I think we could get a D-Bus service started
as part of a user session - but I'm not entirely sure. If anyone knows
more, please chime in...
Does the D-Bus server get started on login? Or is it just started
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.
> > * The information about local changes could be used
not only for
> > automated syncs. For example, Genesis could show the information
> > about changes to the data in the notification area, leaving the
> > start of the sync to the user.
> Yes, this might be useful, but we should design it so that the server
> does not needlessly monitor for changes. Monitoring would require that
> the server runs permanently, and monitoring itself could be costly - not
> so much for EDS, but for other backends (file, for example).
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.
If the server doesn’t permanently monitor for changes, how would one
this information (regardless if for event-based automated syncs or for
There are no good alternatives, so the server really should do it as
good as it can.
> > The problem with that is that Ubuntu removed actions from
> > notifications.
> I suppose that applies to libnotify as well?
Ubuntu introduced a new implementation of the notification demon called
notify-osd. It conforms to the freedesktop spec, but doesn’t implement
everything the old demon did (which isn’t required by the spec). So one
can still use libnotify, but not everything will work with notify-osd,
But to come back to the D-Bus API: I am currently trying to port
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.
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.)
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.
Regarding end of sync, sync_progress_cb() checks for PEV_SYNCEND.
3. Once the sync completed, I get the details by calling
GetSyncReports(). But what do I actually get? What do the values
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
Given that you would end up depending on an under-documented, almost
obsolete D-Bus API in 0.9, would it make more sense to take your
feedback and work on a better API for 1.0 and then release that as soon
as possible, without releasing Genesis for 0.9?
I read through src/dbus/interfaces/syncevo-full.xml, but not
is documented in detail. And I really have a hard time reading the C
Yeah, I can imagine that it'll look nicer in Python. One more reason to
get Genesis ported ;-)
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.