On Thu, 2013-01-31 at 23:32 +0000, Graham Cobb wrote: > I am working on adding --print-databases support in the activesync backend. > In fact I have it working but it has raised a few questions: > > 1) Activesync needs an account before it can connect to a server and get the > folder list. I think that WebDav has the same issue. And, in fact, I stole > the solution from the WebDav code: insist that the source has a username > configured. > > The effect of this is that using just "syncevolution --print-databases" > doesn't show anything, even if you do have an account configured. In fact, > you have to name a "target-config" configuration, and exactly one source, to > get the listing. You can't even set up any configuration of the default > context which will allow "syncevolution --print-databases" to work. > > Is this expected and desired behaviour?
No, desired is to list databases without any configuration if enough information was provided. For WebDAV, that is username/password (as credentials and, if the server supports it, to locate the server) and backend (to choose between events, tasks, memos and contacts). If the WebDAV server doesn't support auto-discovery via an email address, then the syncURL needs to point to the server. Again, depending on the server capabilities, sometimes just the host name is enough, sometimes it has to be the exact URL of the resource collection. > 2) This leads to another question. Other getDatabases implementations only > list databases of the same type as the particular source. However, > particularly as you can't specify several sources at the same time in the > --print-databases command, I am inclined to list all the folders (of all > types) whatever source is specified. > > Would that be regarded as a problem (it also makes the code easier :-))? The reason why databases are listed by data category is that it allows the D-Bus version of --print-databases (GetDatabases() = http://api.syncevolution.org/#Server.GetDatabases) to return entries which are suitable for the given backend. A hypothetical GUI can then decide to pair a local "calendar" backend with the CalDAV backend and one of the databases listed for it. At least that's the theory, I don't think any GUI actually supports that. What SyncEvolution lacks is some meta-information: a GUI has to hard-code compatible backends. Nevertheless it would be good if the ActiveSync backend followed that convention. It's true that this means that it might lead to multiple folder syncs - perhaps the result can be (is?) cached in the activesyncd? > 3) libeasclient exposes an API to list the databases. Unfortunately it is > exposed by the libeasmail code (eas_mail_handler_get_folder_list). > libeasmail > is not used anywhere else in the activesync backend and, in fact, doesn't > even > seem to be usable (the libeasmail.h header file depends on several internal > header files which are not installed)! Is any application actually using > libeasmail? The Evolution UI and camel code in the activesyncd source tree uses it. I suspect that works (accidentally or intentionally) because it has access to the internal headers. Srini, David, is the libeasmail library supposed to be public or is it internal to activesyncd? > eas_mail_handler_get_folder_list works (if I manually copy the parts of the > header file that are needed). But I would prefer to use an API exported by > libeassync as I don't see listing folders as mail-specific. That would mean > adding a new function exported by libeassync and bumping the soname. > Actually, I don't see that the library currently uses sonames -- is that > right? It would mean, in any case, that the new syncevolution backend would > require the new version of the libeasclient library to build. Any problem > with that? No, fine with me. For the syncevolution.org binaries I am compiling and bundling activesyncd. David, should we start to be more serious about versioning the public activesyncd libraries? -- 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
