>Yongsheng, if you can, please review the branch as it exists right now. > I'd like to merge it as soon as we are done with 0.9.1. Ok, no problem. Actually I've been reading it since this Monday. :)
Cheers, Yongsheng -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Patrick Ohly Sent: Wednesday, September 09, 2009 5:05 AM To: Jussi Kukkonen Cc: SyncEvolution Subject: Re: [SyncEvolution] dbus api specification Hello! I have merged this into a heavily rebased (and squashed) "dbus-api" branch. I imported all of the libgdbus history into the "gdbus" branch, similar to how syncclient-sample-config.xml is synchronized with Synthesis upstream. "dbus-api" is now based on that branch. The old syncevo-full.xml is still present. Needs to be removed later on together with adapting the sync-ui, when Jussi is ready. It's safe to base work on "dbus-api" again, we'll coordinate the next rebasing. Changes to be made: * rename Session.Close() => Session.Detach(), because the session might continue to exist. Later we might add a corresponding Attach(). * add more documentation; we've discussed plenty of stuff around these APIs which hasn't been written down yet * merge with Connection API I'll get to this tomorrow morning, before leaving for London. Yongsheng, if you can, please review the branch as it exists right now. I'd like to merge it as soon as we are done with 0.9.1. On Tue, 2009-09-08 at 13:20 +0100, Jussi Kukkonen wrote: [...] > Open issues: > > I think the api is in pretty good shape from my point of view, I've > rebuilt most of the client wrapper object with this for testing > purposes. The last item on the list above is still nagging me a bit, > feel free to take a look... You mean this one? * Server.GetSessions and Server.SessionChanged now have equivalent content (basically only the object path) What exactly nags you about this? That GetSessions() doesn't distinguish between queued and started sessions? > Handling passwords... Patrick, maybe we can go through this on thursday > so we don't miss any corner cases? Yes. Yongsheng's work is relevant for this. I expect that the D-Bus server will become a proxy for a UI running in a client. > Docs: > > The xsl is the counterpart for spec-strip-docs.xsl in the repo, it > creates docbook documentation from the xml files: > %-doc.xml: %-full.xml > $(XSLT) -o $@ $(srcdir)/spec-to-docbook.xsl $< > The docbook can be used by gtkdoc or you can just call docbook2* > converters (which are found in docbook-utils in Debian). When I invoke "docbook2txt syncevo-server-doc.xml" (to take just one example) it prints an error and doesn't produce any output: Using catalogs: /etc/sgml/catalog Using stylesheet: /usr/share/docbook-utils/docbook-utils.dsl#html Working on: /scratch/work/syncevolution/src/dbus/interfaces/syncevo-server-doc.xml jade:/usr/share/sgml/declaration/xml.dcl:31:27:W: characters in the document character set with numbers exceeding 65535 not supported jade:/scratch/work/syncevolution/src/dbus/interfaces/syncevo-server-doc.xml:2:0:E: no document type declaration; will parse without validation Done. According to the man page, XML input files are not supported. I suppose this will have to wait. Do we want to maintain one XML spec file per interface or one spec file for all of them? I have no idea what is easier to handle in libdbus-glib or for merging docs later on. -- 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. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
