Hello, Am Freitag, den 14.08.2009, 10:36 +0300 schrieb Jussi Kukkonen: > >>> 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.
Yes, if it is possible to achieve the goals without having the server always running, that would be nice. > 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? > > >>> 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? I’m not very familiar with EDS. But if it sends a signal on data changes, this is of course the best option for 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. It wasn’t a bug, it was be being unfamiliar with python-dbus... :-( It does work with an empty array when I specify the signature explicitly. It fails with an empty list, because python-dbus can’t guess the signature from that. > > >>> 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 Ah, nice, thanks. That brings me to the idea of reporting the results per source, not for the whole session. I think I’ll play around with that. > 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. Yes, I read the ideas about that. I think I’ll just wait for the API to stabilize and then implement whatever you come up with :-) > > 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. So one could connect to the Progress signal, if one needs the detailed information, or to the SyncSessionEnd signal if one is only interested in the results? Sounds reasonable. By the way, where do I get information about an error? Is that sent through the ServerMessage signal? That currently lacks a description in the API doc, so I didn’t know what it is good for. Cheers, Frederik _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
