From patrick.ohly at gmx.de Mon Oct 10 13:30:42 2011 From: patrick.ohly at gmx.de (Patrick Ohly) Date: Mon, 10 Oct 2011 15:30:42 +0200 Subject: [SyncEvolution] releasing 1.2 / ActiveSync In-Reply-To: <1316305825.2692.4.camel@shinybook.infradead.org> References: <1316015047.11558.91.camel@pohly-mobl1.ikn.intel.com> <1316015774.4818.13.camel@shinybook.infradead.org> <1316068320.11558.100.camel@pohly-mobl1.ikn.intel.com> <1316305825.2692.4.camel@shinybook.infradead.org> Message-ID: <1318253442.14423.96.camel@pohly-mobl1.ikn.intel.com> On Sun, 2011-09-18 at 00:30 +0000, Woodhouse, David wrote: > On Thu, 2011-09-15 at 08:32 +0200, Patrick Ohly wrote: > > I didn't know about that library reorganization plan. Quite the > > opposite, as I recall it, you said something about the API being stable > > and asking when I wanted to move the backend. Oh well ;-) It doesn't > > have to be an atomic commit, so I'd say go ahead and let me know what > > needs to be changed in SyncEvolution, or send a patch. > > The only thing that's changed from your POV is the name of the pkgconfig > file. I've pushed the change to the ActiveSync repo; here's the patch > for SyncEvolution: [...] Thanks, applied to my "pohly" branch, will land in "master" soon. > Please also note http://git.infradead.org/activesyncd.git/commitdiff/c56193ec3 > I don't think it could affect you, because I don't think you can > possibly be getting data out of the d?mon in anything but UTF-8. But > just in case... Ack. The "dbus library aborts on malformed UTF-8" is indeed fun. I've seen that before in the context of malformed vCards. -- 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. From patrick.ohly at gmx.de Fri Oct 7 14:45:53 2011 From: patrick.ohly at gmx.de (Patrick Ohly) Date: Fri, 07 Oct 2011 16:45:53 +0200 Subject: command line: listing databases Message-ID: <1317998753.14423.66.camel@pohly-mobl1.ikn.intel.com> Hello! The current approach of invoking the command line without arguments to list databases has various shortcomings: * unusual "syntax" * cannot limit the output to specific databases * does not work for CalDAV/CardDAV, which needs credentials and/or syncURL Here's a proposal, written as patch for README.rst: =================================================================== SYNOPSIS ======== -Show available sources: - syncevolution +List databases: + syncevolution --print-databases [] [ ] Show information about configuration(s): syncevolution --print-servers|--print-configs|--print-peers @@ -114,15 +114,29 @@ Sometimes it is also useful to change configuration options of a context, without modifying a specific peer. This can be done by using `@default` (or some other context name) without anything before the `at` sign. The empty string "" is the same as `@default`. :: - syncevolution - -If no arguments are given, then SyncEvolution will list all available -data sources regardless whether there is a configuration file for them -or not. The output includes the identifiers which can then be used to -select those sources in a configuration file. For each source one can -set a different synchronization mode in its configuration file. :: + syncevolution --print-databases [] [ ] + +If no additional arguments are given, then SyncEvolution will list all +available backends and the databases that can be accessed through each +backend. This works without existing configurations. However, some +backends need additional information (like credentials or URL of a +remote server) and/or cannot list databases (file backend). This +additional information can be provided on the command line with +property assignments (`username=...`) or in an existing configuration. +The output in these cases explains the required information further. + +Otherwise the output starts with a heading that lists the values for +the `backend` property which select the backend, followed by the databases. +Each database has a name and a unique ID (in brackets). Typically +both can be used as value of the 'database' property. One database +might be marked as `default`. It will be used when `database` is not +set explicitly. + +When selecting an existing source configuration or specifying the `backend` +property on the command line, only the databases for that backend +are listed, using the same output format. ============================================================= Does this make sense? I have partly implemented that because I wanted to test auto-discovery of databases in CalDAV at the CalConnect interoperability test event. I have used it like this to show all address books on a specific server: syncevolution --print-databases \ syncURL=http://... \ username=... \ password=... \ backend=carddav I'm undecided whether listing all databases of all sources in a config should also be supported. Right now, if a config is specified, then a source also must be given ([ ]). Would it be useful to support the [ []] syntax also (= config without source)? This is for the command line. In the D-Bus API, GetDatabases() already is defined per source and can be used on a session where temporary config changes were made, so it should already work without API changes. Long term the returned information should be made a bit richer and also include additional information: * read-only databases => can be mirrored locally, but not be written to * large databases (for example, CardDAV gateways) => only access them in queries, never sync them Related to this change is the removal of and as mandatory. Item operations can work without them, if backend and possibly database are specified as properties on the command line. Not written up yet, but I'll make the change soon. -- 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.