5:32 p.m.
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?
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 :-))?
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?
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?
Graham
4:09 a.m.
On Thursday 31 January 2013 23:32:05 Graham Cobb wrote:
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.
I am already reconsidering this. Most of the folders listed are mail folders,
of course, so aren't even relevant. I think it probably is best to limit by
type, even though it means the user has to set up a source of that type before
they can see the names of the folders.
4:24 a.m.
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.
5:46 a.m.
On Friday 01 February 2013 10:24:15 Patrick Ohly wrote:
On Thu, 2013-01-31 at 23:32 +0000, Graham Cobb wrote:
> 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.
I am still confused about configuration -- I still don't really have a good
model in my head of the way configs work. But help me understand how this
particular case should be working.
Assume that activesyncd gconf is set up correctly (that is a different
problem!). In that case, all the AcriveSync backend needs to be told is the
account name. It expects to get it from the username parameter in the source
config.
For sync, it gets that from the target-config. And my getDatabases code works
if I specify the target config in the --print-databases command, for example:
syncevolution --print-databases target-config@Work calendar
But it would be nice if "syncevolution --print-databases" would work. I tried
to configure a username on the @default config:
syncevolution --configure username=mail(a)company.com @default
But that isn't allowed: "per-peer (unshared) properties not allowed".
Does CalDAV have the same problem or does it have a way to get the required
information without explicitly specifying the configured target-config?
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.
OK. Will do. I will work out a strategy for the caching (activesyncd keeps a
cache -- the question is when to tell it to refresh that cache).
> 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.
OK. That is what I will do. I will propose two patches, one to add a new
function to libeassync and a separate one to use it in ActiveSync.
Thanks for your help Patrick.
8:47 a.m.
On Fri, 2013-02-01 at 11:46 +0000, Graham Cobb wrote:
On Friday 01 February 2013 10:24:15 Patrick Ohly wrote:
> On Thu, 2013-01-31 at 23:32 +0000, Graham Cobb wrote:
> > 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.
I am still confused about configuration -- I still don't really have a good
model in my head of the way configs work. But help me understand how this
particular case should be working.
Assume that activesyncd gconf is set up correctly (that is a different
problem!).
Right. Partly that's why SyncEvolution is not as complete for ActiveSync
as it is for other backends - the expectation was that some other
entity, like an account setup GUI, will configure activesyncd and then
activate SyncEvolution.
In that case, all the AcriveSync backend needs to be told is the
account name. It expects to get it from the username parameter in the source
config.
This part is a bit messy. The "target-config" sync config (see README
for the terminology) was introduced to share several properties between
many different sources (= databases) inside the same peer:
- username/password = for credentials
- WebDAV: syncURL = base URL for accessing the server and locating
individual databases
Later I realized that for the "WebDAV <-> SyncML" sync, there is only
one sync config, and username/password/syncURL are already used for the
SyncML peer.
So I made it possible to user the source database, databaseUsername,
databasePassword properties *in addition* inside the WebDAV backend.
It'll fall back to the corresponding sync properties if the per-source
properties are not set. This is also useful for picking the right
database inside a WebDAV server: if database is empty, it'll do a scan
once to find the default database, then use that.
Sharing credentials by defining them only once as separate entities and
then referencing them elsewhere would be a cleaner solution for parts of
this problem, but hasn't been implemented. It would also be needed for
proper integration into GNOME Online Accounts or Ubuntu's SSO.
For sync, it gets that from the target-config. And my getDatabases
code works
if I specify the target config in the --print-databases command, for example:
syncevolution --print-databases target-config@Work calendar
But it would be nice if "syncevolution --print-databases" would work. I tried
to configure a username on the @default config:
syncevolution --configure username=mail(a)company.com @default
But that isn't allowed: "per-peer (unshared) properties not allowed".
That's because --configure is meant for writing the sync (aka per-peer)
property into some config, and @default doesn't tell SyncEvolution were
to put that.
"syncevolution --print-databases username=mail(a)company.com
backend=eas-contacts" should work. It does because the property is kept
in memory and thus available when the backend asks for it. See
FilterConfigNode and how it gets populated from command line parameters
if you care for the details - one can think of this as a temporary
overlay over the otherwise empty or non-existent config on dist.
Does CalDAV have the same problem or does it have a way to get the
required
information without explicitly specifying the configured target-config?
See above.
--
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.
4:04 p.m.
On Friday 01 February 2013 10:24:15 Patrick Ohly wrote:
On Thu, 2013-01-31 at 23:32 +0000, Graham Cobb wrote:
> 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.
I have created a libeassync version of the function, and moved the main logic
into eas-folder so it is shared for both versions of the function. The patch
is attached to https://bugs.freedesktop.org/show_bug.cgi?id=60204.
I will probably post the patch for the ActiveSync backend getDatabases code,
using this new function, tomorrow.
9:04 a.m.
On Saturday 02 February 2013 22:04:16 Graham Cobb wrote:
I will probably post the patch for the ActiveSync backend
getDatabases
code, using this new function, tomorrow.
I have posted the patch in https://bugs.freedesktop.org/show_bug.cgi?id=60235.
Note that I posted the wrong patch first, please use the updated patch. Of
course it is dependent on the patch in bug 60204.
I am no C++ programmer so you may want to review the patch before applying.
It seems to work fine in my testing but you might want to check I haven't
introduced memory leaks or similar issues. Note I have only tested against a
MS Exchange 2010 server (all I have access to).
By the way, I decided that getDatabases would force a FolderSync, even though
activesyncd keeps a folder cache. FolderSyncs are not particularly expensive
if nothing has changed (the server just says nothing has changed, it doesn't
resend the whole list). I anticipate that getDatabases is a fairly rare event
(compared with syncs, for example) and is most likely to be requested exactly
when something has changed. It also, conveniently, provides a way for the
user to force a FolderSync if they need to (I still haven't been able to
reproduce the problem of the server insisting on a FolderSync).
I considered not doing the FolderSync if the folder list is already in memory
but I decided that this doesn't help the most common use case (separate
"syncevolution --print-databases username= backend=" commands for each
backend) and could be a problem if syncevolution was running as a long-lived
server process. Adding timers seemed unnecessarily complicated.
Graham
5:13 a.m.
On Fri, 2013-02-01 at 11:24 +0100, Patrick Ohly wrote:
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?
It's theoretically supposed to be public — although, as you observed, it
has no users outside the activesyncd git tree so it gets away with a lot
of things it shouldn't. Like including other header files that aren't
actually installed outside the activesyncd build tree.
Note it is *part* of the libeasclient library now, not a separate
libeasmail library.
> 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.
In the general case, you don't need to bump the soname for adding a new
function; it doesn't *break* backward-compatibility. You just need to
bump the *minor* number (which doesn't appear in the soname). And list
it with the appropriate version in the symbol version list.
> 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?
Yes, I think that would be a good thing. I'm happy enough to apply the
get_folder_list change that Graham is suggesting, too.
--
Sent with MeeGo's ActiveSync support.
David Woodhouse Open Source Technology Centre
David.Woodhouse(a)intel.com Intel Corporation
7:40 a.m.
On Monday 04 February 2013 11:13:02 Woodhouse, David wrote:
In the general case, you don't need to bump the soname for adding
a new
function; it doesn't *break* backward-compatibility. You just need to
bump the *minor* number (which doesn't appear in the soname). And list
it with the appropriate version in the symbol version list.
Thanks - I am always making this mistake in terminology. Must try harder :-)
I am an old VAX/VMS system programmer and the equivalent VMS construct
contained both the major and minor numbers in a single entity (GSMATCH). I
always forget that the soname doesn't include the minor number.
But then VMS didn't even have true dynamic linking -- I don't miss the
delights of "transfer vectors"!
2910
days inactive
2914
days old
syncevolution@synevolution.org
8 comments
3 participants
participants (3)
-
Graham Cobb -
Patrick Ohly -
Woodhouse, David