On Fri, 2011-08-26 at 07:39 +0200, Milan Crha wrote: > sounds good. One thing for a process name, it would be better to call it > evolution-source-registry, because Chen mentioned similar for factories > as well, but we never took a consensus on it and thus their name was > never changed.
Yeah, maybe. I think the bus name is more important than the process name. Currently we have: org.gnome.evolution.dataserver.AddressBook1 org.gnome.evolution.dataserver.Calendar1 perhaps the new service would be named: org.gnome.evolution.dataserver.Sources0 > One question comes on my mind: what will consumers do if the registry > process crashes? As long as you want to make it extensible, and the > example of exchange extension of doing stuff on a server, then it can > sometime result in a crash for sure. And seeing a flood panic on all > consumers might be sort of fun. Reconnect? The usage pattern I envision for proxy object is to connect, obtain all the sources somehow (details TBD), and then just listen for the occasional add/remove/change signal. If the proxy has to reconnect and refresh its set of sources, it's trivial to filter out by UID the sources it already knows about. Point is, all the details should be hidden in the proxy object. Should be transparent to clients. > Pity I didn't notice existence of the GDBus code generation tool before > I wrote all the templates for GDBus calls by hand. Though with all those > macros it seems to me like easier to read, if anyone would ever like to > read it. ;) I think David added the code generation shortly after you wrote all that out by hand. I remember thinking of the irony when that landed. We could look into using the code generation tools for 3.4 if you think it's worth it. Since it's in GLib now I don't think we'll get stuck in the "generate once and it rots forever" trap like last time. _______________________________________________ evolution-hackers mailing list email@example.com To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers