Hi, Am Mittwoch, den 29.07.2009, 11:00 +0200 schrieb Patrick Ohly: > I suppose you wanted to keep this on the list, so I'm copying the list > again.
Oops, of course. Thank you! > 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... Yes, I see, a running user session makes sense. > > 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. 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). > > 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. > > 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.) > > 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. > Regarding end of sync, sync_progress_cb() checks for PEV_SYNCEND. That should be sufficient for the moment. :-) > > 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. > 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? Yes, that sounds reasonable. I think the syncevolution output did’t change all that much, so maybe I’ll try updating the regexes for an intermediary release that works with 0.9, but doesn’t use the D-Bus API. Cheers, Frederik _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
