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.