On Mon, 2011-11-14 at 10:00 +0100, Patrick Ohly wrote:
So I suggest to pursue the first approach instead. I think it is
possible for the file backend.
Is it also possible for other backends? Or are some unable to store
the UID and look up contacts (efficiently) by it? In that case we will
On Mo, 2011-11-14 at 11:22 +0100, Milan Crha wrote:
On Mon, 2011-11-14 at 10:00 +0100, Patrick Ohly wrote:
So I suggest to pursue the first approach instead. I think it is
possible for the file backend.
Is it also possible for other backends? Or are some unable to store
the UID and
On Mon, 2011-11-14 at 21:06 +0100, Patrick Ohly wrote:
On Mo, 2011-11-14 at 11:22 +0100, Milan Crha wrote:
On Mon, 2011-11-14 at 10:00 +0100, Patrick Ohly wrote:
So I suggest to pursue the first approach instead. I think it is
possible for the file backend.
Is it also possible for
On Mon, 2011-11-14 at 21:06 +0100, Patrick Ohly wrote:
On Mo, 2011-11-14 at 11:22 +0100, Milan Crha wrote:
On Mon, 2011-11-14 at 10:00 +0100, Patrick Ohly wrote:
So I suggest to pursue the first approach instead. I think it is
possible for the file backend.
Is it also possible for
I have severed all of Camel's remaining dependencies on libedataserver,
mostly by way of code duplication. In particular, all of Camel's search
and filtering code now uses CamelSExp, which is a clone of ESExp.
libcamel now builds first in the evolution-data-server module, and its
pkg-config file
On Mon, 2011-11-14 at 21:06 +0100, Patrick Ohly wrote:
What about a CardDAV server? It has server-supplied IDs (the path to the
resource) and a UID as part of the vCard stored there? How is that
handled at the moment?
Hi,
there is no exact support for CardDAV as such, the closest is
