Hi Patrick,
Am Mittwoch 16 November 2011, um 15:55:54 schrieb Patrick Ohly:
Hello!
[...]
On Di, 2011-11-15 at 15:01 +0100, Christian Hilberg wrote:
If a new UID is to be created, it is the responsibility of the Kolab client
to
assign one. The Kolab server itself is unaware to object
On Fri, 2011-11-18 at 11:23 +0100, Christian Hilberg wrote:
Am Mittwoch 16 November 2011, um 15:55:54 schrieb Patrick Ohly:
Hello!
[...]
On Di, 2011-11-15 at 15:01 +0100, Christian Hilberg wrote:
If a new UID is to be created, it is the responsibility of the Kolab
client to
assign
Hi,
Am Freitag 18 November 2011, um 16:53:38 schrieb Patrick Ohly:
On Fri, 2011-11-18 at 11:23 +0100, Christian Hilberg wrote:
[...]
While the E-D-S client (like Evo) might not be interested whether it is
a Kolab backend being used, there is still one thing you may wish to
consider
On Mon, 2011-11-14 at 10:00 +0100, Patrick Ohly wrote:
Hello!
I'd like to write down some thoughts on vCard UID handling in EDS.
Andrew mentioned it on IRC, so I'm copying him.
Let me define the terms to make the difference clear:
* UID: part of the contact properties. Ideally set
Hello!
Before I reply to Christian, let me elaborate a bit more on why
overwriting the UID is bad for syncing. I thought it was obvious, but
probably not ;-}
What I have in mind is a system where contact data moves freely and
ad-hoc between peers, without being forced to go through a central
On mié, 2011-11-16 at 15:55 +0100, Patrick Ohly wrote:
CouchDB comes close, but is a closed system. You also cannot create two
independent CouchDB instances and then merge them (at least that is my
understanding - I might be wrong on that particular aspect).
not sure what you mean, but if
On Di, 2011-11-15 at 10:50 +0100, Christian Hilberg wrote:
Hi everyone,
Am Montag 14 November 2011, um 11:22:57 schrieb Milan Crha:
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.
Am Dienstag 15 November 2011, um 15:01:54 schrieb Christian Hilberg:
Am Dienstag 15 November 2011, um 11:03:24 schrieb Patrick Ohly:
[...]
What happens during syncing? Do you resolve the add-add conflict by
duplicating the item, merging them or discarding one copy?
This is a
On Tue, 2011-11-15 at 08:41 +0100, Milan Crha wrote:
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
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
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
14 matches
Mail list logo
