Re: [Evolution-hackers] UID in vCard

2011-11-20 Thread Patrick Ohly
On Fri, 2011-11-18 at 17:27 +0100, Christian Hilberg wrote:
 Am Freitag 18 November 2011, um 16:53:38 schrieb Patrick Ohly:
  On Fri, 2011-11-18 at 11:23 +0100, Christian Hilberg wrote:
That is the whole point of this mail thread: a vCard UID may have a
meaning outside of the storage in which it currently exists. EDS cannot
know whether that is the case. Currently it assumes that the UID has no
meaning and throws it away when adding contacts.
   
   Not globally true. The file backend may do so, but it is the backend 
   implementation
   deciding whether re-writing a UID or not. E-D-S cannot decide that, since 
   it does
   not know what a given backend is dealing with.
  
  What I meant is the Evolution/EDS API expectation that adding a contact
  will never fail because of a UID conflict. Whether the backend
  implements that by always overwriting the UID (as the file backend does)
  or by keep it when possible and overwriting otherwise (as in the Kolab
  backend) is indeed a backend implementation detail.
 
 From evolution-kolab's point of view, it would be simple to return a
 *mp* UID already exists, try again-error to E-D-S in that case,
 provided the E-D-S API for that existed.

As Matthew said, the Evolution UI itself is probably not able to handle
such an error at the moment. So at the end of the day, it might be the
client which has to tell EDS+backend and/or libebook which behavior it
wants: preserve UID at all costs (including throwing errors) or emulate
the current semantic (don't throw errors, overwrite UID if necessary).

  But it has the same effect: a libebook user cannot reliably detect an
  add-add UID conflict. It can check for a contact with the UID first
  (by assuming that ID in the libebook API == UID in vCard), but then
  there's still a race condition between that check and creating that
  contact.
 
 Again, in Kolab context, the user of the calendar lib or addressbook lib
 would still get a vague indication only. The race condition could still
 occur, since there is (a) no transactional system provided by the Kolab server
 for PIM object creation and (b) any Kolab client is required to fully work
 in offline mode.

This leads to another pet peeve of mine: all backends should be able to
work in read/write offline mode. This implies syncing between local and
remote data when going online, which should be provided as a core
feature of EDS instead of being replicated in every single backend.
Akonadi provides such a feature.

I have some ideas how SyncEvolution could be used for that inside
EDS/Evolution, but that's a topic for another day and mail thread...

 AFAICS, the following may be a good start:
 * have E-D-S generate good UUIDs
 * give the backends the chance to report if a UUID already exists
   (if the error does not pop up instantly, it does not mean everything
   is well, but *if* it does, certainly E-D-S can try again and generate
   another UID, and notify the user)
 * encourage all backend implementors not to overwrite existing UIDs,
   if at all possible

Agreed.

-- 
Bye, Patrick Ohly
--  
patrick.o...@gmx.de
http://www.estamos.de/


___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] UID in vCard

2011-11-18 Thread Christian Hilberg
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 UIDs and will not 
  touch
  them (no read/write/anything).
 With client, I meant an EDS client here (= the application using
 libebook). That there is a Kolab client and server involved is of course
 important for you, but not so much for a user of the abstract libebook
 API ;-)

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 
here.
We could of course map between Kolab PIM object UIDs and E-D-S UUIDs in our
backend. The E-D-S client (like Evo) would then see UUIDs and be happy with it.
Now imagine someone in Evo exports a PIM object which originates from a Kolab
server. Evo would write the E-D-S UUID into that PIM object. Now, by some nice
round-trip, this exported PIM object would reach a user of the Kolab server
it originated from. By importing the object into the Kolab server, we would then
generate a dupe, since the Kolab UID for a PIM object *is* the iCal/vCard UID
of an object stored. While this would have the potential of being a self-healing
process over time (a PIM object duplication is detected, the one with the UID 
which
is not UUID is deleted), it would take a very long time for the healing to be
completed, and only then you could really rely on the assents a UUID makes.
  To give you a hint about the numbers we're talking about, it is not uncommon 
for
a Kolab deployment to host thousands of contacts and incident types, potentially
shared among hundreds of users with various clients.
  Implementing UUIDs in our backend, as I said, is not an issue. The issue is
more like what to you gain if you cannot rely on the UID you see to be really
globally unique. In Kolab context (that's why I'm talking about it here), a 
mapping
between Kolab-UID and E-D-S-UUID would not help you in PIM data exchange and 
sync
interplay.

   How does the backend work at the moment? Does it always overwrite an
   existing UID like the file backend does or does it already work as I
   proposed?
  
  Existing UIDs are (and must be) preserved. This is a requirement for Kolab 
  client
  interop, since they all rely on the object's UID to reference it 
  (especially regarding
  changes to the contents of the PIM object). In Kolab, there is no way to
  correctly reference an object other than using its UID.
  
   If it does, do you throw a
   E_BOOK_ERROR_CONTACT_ID_ALREADY_EXISTS when the existing UID is not
   unique?
  
  Eeewww. :-) evolution-kolab presently sits on Evo/EDS 2.30.3 (which some 
  like
  to call just plain old here =). No error message in that case. If the UID
  already exists, it gets rewritten. It was a tradeoff here - an existing 
  Kolab
  object and its UID superseedes a new one. Imported objects are regarded as
  new (being assigned a new UID), should the UID they carry already exist in
  the given PIM folder. The original UID would do no good in the Kolab context
  if another object with that same UID already exists, since other groupware
  clients do have an idea about the object this UID refers to already. Trying
  to find out whether the imported object could actually be an update for an
  already existing one seemed too complex and out-of-scope for the initial
  evolution-kolab implementation. We're now porting to current Evo/EDS git 
  master,
  but I would still keep the current implementation unchanged when it comes
  to how to interpret UIDs of imported objects.
 
 That is the whole point of this mail thread: a vCard UID may have a
 meaning outside of the storage in which it currently exists. EDS cannot
 know whether that is the case. Currently it assumes that the UID has no
 meaning and throws it away when adding contacts.

Not globally true. The file backend may do so, but it is the backend 
implementation
deciding whether re-writing a UID or not. E-D-S cannot decide that, since it 
does
not know what a given backend is dealing with. For the evolution-kolab backend,
only those UIDs are rewritten which do already exist on the Kolab server. UUIDs
would, as a matter of fact, be helpful here. There is *some* risk, however, that
by chance you generate a UUID for a PIM object, and may find that even this one
exists on the server, because out of full randomness, a UUID-unaware Kolab 
client
hase decided that exactly *this* would be the UID string it would want to use 
today.
Granted, this is a corner case and it should hit so very seldom that manual 
intervention
would be acceptable.
  My point is, that you might be very well able to make good use of UUIDs if you
implemented a fully new system, which would enforce all clients to be using 
UUIDs and
all servers dealing with objects checking that the UID 

Re: [Evolution-hackers] UID in vCard

2011-11-18 Thread Patrick Ohly
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 one. The Kolab server itself is unaware to object UIDs and will 
   not touch
   them (no read/write/anything).
  With client, I meant an EDS client here (= the application using
  libebook). That there is a Kolab client and server involved is of course
  important for you, but not so much for a user of the abstract libebook
  API ;-)
 
 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 
 here.
 We could of course map between Kolab PIM object UIDs and E-D-S UUIDs in our
 backend.

That should never be necessary. As you said, having such two different
ids doesn't buy the user much. Only a radical step away from do what
you want with UID to UID must be UUID and preserved will - not
realistic anytime soon, but at least a proof-of-concept would be nice.

  That is the whole point of this mail thread: a vCard UID may have a
  meaning outside of the storage in which it currently exists. EDS cannot
  know whether that is the case. Currently it assumes that the UID has no
  meaning and throws it away when adding contacts.
 
 Not globally true. The file backend may do so, but it is the backend 
 implementation
 deciding whether re-writing a UID or not. E-D-S cannot decide that, since it 
 does
 not know what a given backend is dealing with.

What I meant is the Evolution/EDS API expectation that adding a contact
will never fail because of a UID conflict. Whether the backend
implements that by always overwriting the UID (as the file backend does)
or by keep it when possible and overwriting otherwise (as in the Kolab
backend) is indeed a backend implementation detail.

But it has the same effect: a libebook user cannot reliably detect an
add-add UID conflict. It can check for a contact with the UID first
(by assuming that ID in the libebook API == UID in vCard), but then
there's still a race condition between that check and creating that
contact.

-- 
Bye, Patrick Ohly
--  
patrick.o...@gmx.de
http://www.estamos.de/


___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] UID in vCard

2011-11-18 Thread Christian Hilberg
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 here.
  We could of course map between Kolab PIM object UIDs and E-D-S UUIDs in our
  backend.
 
 That should never be necessary. As you said, having such two different
 ids doesn't buy the user much. Only a radical step away from do what
 you want with UID to UID must be UUID and preserved will - not
 realistic anytime soon, but at least a proof-of-concept would be nice.

Writing UIDs as UUIDs only would definitely be a good thing to start with.

   That is the whole point of this mail thread: a vCard UID may have a
   meaning outside of the storage in which it currently exists. EDS cannot
   know whether that is the case. Currently it assumes that the UID has no
   meaning and throws it away when adding contacts.
  
  Not globally true. The file backend may do so, but it is the backend 
  implementation
  deciding whether re-writing a UID or not. E-D-S cannot decide that, since 
  it does
  not know what a given backend is dealing with.
 
 What I meant is the Evolution/EDS API expectation that adding a contact
 will never fail because of a UID conflict. Whether the backend
 implements that by always overwriting the UID (as the file backend does)
 or by keep it when possible and overwriting otherwise (as in the Kolab
 backend) is indeed a backend implementation detail.

From evolution-kolab's point of view, it would be simple to return a
*mp* UID already exists, try again-error to E-D-S in that case,
provided the E-D-S API for that existed.

 But it has the same effect: a libebook user cannot reliably detect an
 add-add UID conflict. It can check for a contact with the UID first
 (by assuming that ID in the libebook API == UID in vCard), but then
 there's still a race condition between that check and creating that
 contact.

Again, in Kolab context, the user of the calendar lib or addressbook lib
would still get a vague indication only. The race condition could still
occur, since there is (a) no transactional system provided by the Kolab server
for PIM object creation and (b) any Kolab client is required to fully work
in offline mode. While offline, we can check in our local cache whether
a UID collision was about to occur and return the corresponding error message
to E-D-S. Assume there was no UID collision in offline mode, it may well
show up when we're going online again some time later. Imagine, while in
offline mode, the PIM object in question has been exported already, carrying
the believed-to-be-unique ID, while the object in the offline cache faces a UID
collision when being spooled onto the server. Even if we fail to spool that
object onto the server since we detected an add-add collision there,
and ask the user for some interaction, we may already have the exported-
in-offline-mode-object circulate elsewhere, e.g. by sending it via email,
playing funny tricks on us when we try to rely on its UUID.

As you can see, we can play this game back and forth. AFAICS, the following
may be a good start:
* have E-D-S generate good UUIDs
* give the backends the chance to report if a UUID already exists
  (if the error does not pop up instantly, it does not mean everything
  is well, but *if* it does, certainly E-D-S can try again and generate
  another UID, and notify the user)
* encourage all backend implementors not to overwrite existing UIDs,
  if at all possible

Just 2 cents,

Christian

-- 
kernel concepts GmbH   Tel: +49-271-771091-14
Sieghuetter Hauptweg 48
D-57072 Siegen
http://www.kernelconcepts.de/


signature.asc
Description: This is a digitally signed message part.
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] UID in vCard

2011-11-16 Thread Chenthill
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 once when a new
 contact is created in such a way that it is globally unique
 (same semantic as iCalendar 2.0 UID, not just unique inside the
 current address book). Can and should be passed around and
 preserved when exporting/importing contacts.
   * local ID: local meta data about a contact, only relevant inside
 an address book to look up contacts. 
 
 The current situation is that EDS uses the vCard UID property for its
 own local ID. When trying to create a new contact with UID already set,
 that UID will be overwritten.
 
 This is problematic for interoperability (one cannot store a vCard
 as-is) and syncing (which would benefit considerably from a
 creator-assigned, fixed UID).
 
 This is partly an API and partly an implementation issue. The
 libebook-e_addressbook_factory D-Bus API just passes vCards, so a
 vCard property has to be used for any local ID, and UID is the one that
 is used.
 
 e_book_add_contact() doesn't have an explicit local ID retval. Clients
 have to use e_contact_get_const(contact, E_CONTACT_UID) to retrieve the
 assigned local ID. Other APIs avoid that. For example,
 e_book_add_contact_async() + EBookIdAsyncCallback return the ID
 out-of-band.
 
 The more recent EBookClient API always uses separate ID retvals.
 However, in contrast to the EBook API it specifies that these are the
 UID of the created contact and not some kind of local ID. The older API
 left that undefined and just talked of id.
 
 I see several ways forward:
  1. Accept that a contact ID as used in the EBook API is the vCard
 UID and make it possible to set that UID when creating a new
 contact. That implies for adding a contact:
   * remove the code which overwrites the UID
   * add check for existence of the UID in the address book
 and a corresponding error code if it does
  2. Use the local ID in the EBook API and support storing the vCard
 UID separately. Support lookup of a contact by UID.
 
 The advantage of the second approach is that it is potentially more
 efficient. I myself took advantage of that in the EDS-QtContacts
 bridge code. But it never was a full solution (depended on 32 bit local
 IDs, which is okay for the file backend, but not all of them, and
 required patching EDS).
 
 The disadvantage of the second approach is an API change and/or
 extension. It has some potential advantages, but as the EDS-QtContacts
 bridge is not used anymore, there is little incentive to do the extra
 work right away.
 
 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 have
 to relax the semantic of the API and accept that some backends still use
 their own local ID. Supports UID should be defined as a capability of
 the backend so that clients can take it into account.

Just went through the thread and had a small discussion with mcrha. My
preference goes with the first approach along with having the static
capability.

- Chenthill.

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] UID in vCard

2011-11-16 Thread Patrick Ohly
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
server, stick to a fixed topology or use a specific database technology.
This cannot be done with today's technology because avoiding duplicates
becomes unreliable.

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).

A creator-assigned global UID would be the right way of solving this.
Storages or systems which do create and preserve such a UID cannot
participate in that system. I'd like to make sure that the EDS file
backend can be part of it, even if it is just for experiments.

For more details, see the TODOs on ad-hoc synchronization in
http://syncevolution.org/blogs/pohly/2011/state-union-version-12

On Di, 2011-11-15 at 15:01 +0100, Christian Hilberg wrote:
 Am Dienstag 15 November 2011, um 11:03:24 schrieb Patrick Ohly:
  On Di, 2011-11-15 at 10:50 +0100, Christian Hilberg wrote:
  [...] 
   Just adding a few bits on how the situation is for the Kolab groupware 
   server.
   
   The evolution-kolab backend cannot ask the Kolab server for a UID (since 
   there
   is no API for that) nor does the server enforce certain UIDs on a PIM 
   object (but,
   of course, that there be one). The only requirement is that the PIM 
   object's UID
   be unique in a given PIM folder. If the UID is globally unique, all the 
   better.
  
  That's the same situation as with the file backend then: a client could
  decide to set a UID in the vCard before creating the contact, and the
  Kolab backend+server would use that UID instead of creating their own.
  Good :-)
 
 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 UIDs and will not 
 touch
 them (no read/write/anything).

With client, I meant an EDS client here (= the application using
libebook). That there is a Kolab client and server involved is of course
important for you, but not so much for a user of the abstract libebook
API ;-)

  How does the backend work at the moment? Does it always overwrite an
  existing UID like the file backend does or does it already work as I
  proposed?
 
 Existing UIDs are (and must be) preserved. This is a requirement for Kolab 
 client
 interop, since they all rely on the object's UID to reference it (especially 
 regarding
 changes to the contents of the PIM object). In Kolab, there is no way to
 correctly reference an object other than using its UID.
 
  If it does, do you throw a
  E_BOOK_ERROR_CONTACT_ID_ALREADY_EXISTS when the existing UID is not
  unique?
 
 Eeewww. :-) evolution-kolab presently sits on Evo/EDS 2.30.3 (which some like
 to call just plain old here =). No error message in that case. If the UID
 already exists, it gets rewritten. It was a tradeoff here - an existing Kolab
 object and its UID superseedes a new one. Imported objects are regarded as
 new (being assigned a new UID), should the UID they carry already exist in
 the given PIM folder. The original UID would do no good in the Kolab context
 if another object with that same UID already exists, since other groupware
 clients do have an idea about the object this UID refers to already. Trying
 to find out whether the imported object could actually be an update for an
 already existing one seemed too complex and out-of-scope for the initial
 evolution-kolab implementation. We're now porting to current Evo/EDS git 
 master,
 but I would still keep the current implementation unchanged when it comes
 to how to interpret UIDs of imported objects.

That is the whole point of this mail thread: a vCard UID may have a
meaning outside of the storage in which it currently exists. EDS cannot
know whether that is the case. Currently it assumes that the UID has no
meaning and throws it away when adding contacts.

Consider sending around vCard with globally unique UID. A user might
import that vCard once into Kolab using Kolab client A. Then when he
tries again with Kolab client B, the client can warn him reliably that
this particular contact was already imported.

   PIM objects already residing on the Kolab server do carry a UID, created 
   by the
   client which created the object (evolution-kolab, Kontact, Horde, Outlook 
   with
   a Kolab connector, Thunderbird via Lightning/SyncKolab, ...).
  
  Do you attempt to make the UID globally unique, for example by using a
  UUID?
 
 In our current implementation, the UID will be unique to the Kolab server at 
 hand.
 Since the Kolab server does not impose specific restrictions on the format of 
 the
 UID, evolution-kolab could change the UID generation code (we currently use 
 E-D-S
 

Re: [Evolution-hackers] UID in vCard

2011-11-16 Thread Rodrigo Moya
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 I've understood correctly, you are
wrong :-) You can create 2 couchdb instances and then sync them.

cheers

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] UID in vCard

2011-11-15 Thread Christian Hilberg
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.
  
  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
  have to relax the semantic of the API and accept that some backends
  still use their own local ID. Supports UID should be defined as a
  capability of the backend so that clients can take it into account.
 
   Hi,
 I wouldn't call it local UID, it's rather backend's UID and mostly
 not, this is not doable for groupware backends which are using
 server-supplied unique identifiers for contacts/calendars, like message
 IDs in evolution-mapi, which talks to Exchange servers. It's easier, and
 makes sense, to use server-side IDs, which are meant to be unique.
 It's also a reason, from my point of view, why
 e_data_book_respond_create_contacts() passes UIDs of newly created
 objects back to the client.
 [...]

Just adding a few bits on how the situation is for the Kolab groupware server.

The evolution-kolab backend cannot ask the Kolab server for a UID (since there
is no API for that) nor does the server enforce certain UIDs on a PIM object 
(but,
of course, that there be one). The only requirement is that the PIM object's UID
be unique in a given PIM folder. If the UID is globally unique, all the better.

PIM objects already residing on the Kolab server do carry a UID, created by the
client which created the object (evolution-kolab, Kontact, Horde, Outlook with
a Kolab connector, Thunderbird via Lightning/SyncKolab, ...). An existing UID of
a PIM object must be retained, of course. Every Kolab client will follow its own
approach creating UIDs. Possible clashes need to be handled by the clients. When
creating a new PIM object, the Kolab client needs to create a UID for it. Kolab
objects are referenced by folder/UID in evolution-kolab. While mapping between
a E-D-S backend UID and the Kolab UID would be certainly possible, it would
require another level of lookups, which has the potential for being inefficient.

When it comes to importing a PIM object, it is not possible to retain its
UID in the cases where the same UID exists on the server already for another PIM
object (unlikely, but possible, since Kolab object UIDs are not required to be
globally unique). As long as we're in offline mode, we may at first succeed 
retaining
the object's UID, but when going online any syncing with the server, find that
a new UID must be set on the object.

No final statement here, just a dump of what came to mind. :-)

So here's my 2 cents,

Christian

-- 
kernel concepts GmbH   Tel: +49-271-771091-14
Sieghuetter Hauptweg 48
D-57072 Siegen
http://www.kernelconcepts.de/


signature.asc
Description: This is a digitally signed message part.
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] UID in vCard

2011-11-15 Thread Patrick Ohly
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.
   
   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
   have to relax the semantic of the API and accept that some backends
   still use their own local ID. Supports UID should be defined as a
   capability of the backend so that clients can take it into account.
  
  Hi,
  I wouldn't call it local UID, it's rather backend's UID and mostly
  not, this is not doable for groupware backends which are using
  server-supplied unique identifiers for contacts/calendars, like message
  IDs in evolution-mapi, which talks to Exchange servers. It's easier, and
  makes sense, to use server-side IDs, which are meant to be unique.
  It's also a reason, from my point of view, why
  e_data_book_respond_create_contacts() passes UIDs of newly created
  objects back to the client.
  [...]
 
 Just adding a few bits on how the situation is for the Kolab groupware server.
 
 The evolution-kolab backend cannot ask the Kolab server for a UID (since there
 is no API for that) nor does the server enforce certain UIDs on a PIM object 
 (but,
 of course, that there be one). The only requirement is that the PIM object's 
 UID
 be unique in a given PIM folder. If the UID is globally unique, all the 
 better.

That's the same situation as with the file backend then: a client could
decide to set a UID in the vCard before creating the contact, and the
Kolab backend+server would use that UID instead of creating their own.
Good :-)

How does the backend work at the moment? Does it always overwrite an
existing UID like the file backend does or does it already work as I
proposed? If it does, do you throw a
E_BOOK_ERROR_CONTACT_ID_ALREADY_EXISTS when the existing UID is not
unique?

 PIM objects already residing on the Kolab server do carry a UID, created by 
 the
 client which created the object (evolution-kolab, Kontact, Horde, Outlook with
 a Kolab connector, Thunderbird via Lightning/SyncKolab, ...).

Do you attempt to make the UID globally unique, for example by using a
UUID?

 When it comes to importing a PIM object, it is not possible to retain its
 UID in the cases where the same UID exists on the server already for another 
 PIM
 object (unlikely, but possible, since Kolab object UIDs are not required to be
 globally unique). As long as we're in offline mode, we may at first succeed 
 retaining
 the object's UID, but when going online any syncing with the server, find that
 a new UID must be set on the object.

What happens during syncing? Do you resolve the add-add conflict by
duplicating the item, merging them or discarding one copy?


-- 
Bye, Patrick Ohly
--  
patrick.o...@gmx.de
http://www.estamos.de/


___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] UID in vCard

2011-11-15 Thread Christian Hilberg
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 configuration option the user has. Kontact, as a reference client 
 for Kolab,
 will ask you in all events of synchronization conflicts. In Evo/EDS 2.30, we 
 did not
 have the infrastructure needed to query Kolab-specific user input from Evo, 
 so the whole
 thing is non-interactive. For each PIM folder, you can configure the backends 
 to use
 one of the following strategies:
 * use the newer PIM object (relies on timestamps - since these are set by 
 the clients,
   not the Kolab server, it only works if the client's clocks are synced)
 * use the client's object (overwrites the one on the server)
 * use the server's object (discards the client's changes)
 * create a duplicate

Adding some more bits: The evolution-kolab user manual has some more info on
the current behaviour of the plugin in 3.4.2 Conflict solving strategies,
see [1].

Kind regards,

Christian


[1] 
http://sourceforge.net/projects/evolution-kolab/files/evolution-kolab_user-manual_v1.3.pdf/download

-- 
kernel concepts GmbH   Tel: +49-271-771091-14
Sieghuetter Hauptweg 48
D-57072 Siegen
http://www.kernelconcepts.de/


signature.asc
Description: This is a digitally signed message part.
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] UID in vCard

2011-11-15 Thread Andrew McMillan
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 is no exact support for CardDAV as such, the closest is the WebDAV
 backend, and it generates its own UID too, and it also can download just
 added contact from the server. It use eTag value as a revision value.

hi Milan,

The WebDAV backend for the addressbook works fine against a CardDAV
server.  Unlike CalDAV where there are substantial differences between
WebDAV calendars and CalDAV, WebDAV for addressbooks is a compatible
subset of CardDAV.

Cheers,
Andrew.
-- 

andrew (AT) morphoss (DOT) com+64(272)DEBIAN
   Does the name Pavlov ring a bell?




signature.asc
Description: This is a digitally signed message part
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] UID in vCard

2011-11-14 Thread 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.
 
 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
 have to relax the semantic of the API and accept that some backends
 still use their own local ID. Supports UID should be defined as a
 capability of the backend so that clients can take it into account.

Hi,
I wouldn't call it local UID, it's rather backend's UID and mostly
not, this is not doable for groupware backends which are using
server-supplied unique identifiers for contacts/calendars, like message
IDs in evolution-mapi, which talks to Exchange servers. It's easier, and
makes sense, to use server-side IDs, which are meant to be unique.
It's also a reason, from my point of view, why
e_data_book_respond_create_contacts() passes UIDs of newly created
objects back to the client.

For example with Google calendar, which is served by CalDAV backend, the
backend fetches newly added event from the server only to present UI
with real object from the server, because the server can modify the
event on its own when creating it (it adds default alarms, if set in
Google's calendar preferences on the Web).

Just my quick ideas on the issue, if I got it right.
Bye,
Milan

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] UID in vCard

2011-11-14 Thread Patrick Ohly
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 look up contacts (efficiently) by it? In that case we will
  have to relax the semantic of the API and accept that some backends
  still use their own local ID. Supports UID should be defined as a
  capability of the backend so that clients can take it into account.
 
   Hi,
 I wouldn't call it local UID, it's rather backend's UID

I wouldn't use the term UID at all for this local (or backend) ID. UID
has a specific meaning for both iCalendar 2.0 (where it is well-defined)
and vCard (where it is less well-defined). Introducing yet another
flavor of UID just leads to confusion, in particular when the same
contact has both the original vCard UID and a local backend UID.

  and mostly
 not, this is not doable for groupware backends which are using
 server-supplied unique identifiers for contacts/calendars, like message
 IDs in evolution-mapi, which talks to Exchange servers. It's easier, and
 makes sense, to use server-side IDs, which are meant to be unique.
 It's also a reason, from my point of view, why
 e_data_book_respond_create_contacts() passes UIDs of newly created
 objects back to the client.

So we do need the concept of local IDs which are not the same as the
creator-assigned UID.

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?

And what does that mean for the file backend? I still think it would be
good if the file backend supported creator-assigned UIDs. That other
backends can't do that doesn't mean that file backend is not allowed to
do it, right?

 For example with Google calendar, which is served by CalDAV backend, the
 backend fetches newly added event from the server only to present UI
 with real object from the server, because the server can modify the
 event on its own when creating it (it adds default alarms, if set in
 Google's calendar preferences on the Web).

Are you saying that Google Calendar EDS does *not* report the original
iCalendar 2.0 UID?


-- 
Bye, Patrick Ohly
--  
patrick.o...@gmx.de
http://www.estamos.de/


___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] UID in vCard

2011-11-14 Thread Adam Tauno Williams
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 other backends? Or are some unable to store
   the UID and look up contacts (efficiently) by it? In that case we will
   have to relax the semantic of the API and accept that some backends
   still use their own local ID. Supports UID should be defined as a
   capability of the backend so that clients can take it into account.
  I wouldn't call it local UID, it's rather backend's UID
 I wouldn't use the term UID at all for this local (or backend) ID. UID
 has a specific meaning for both iCalendar 2.0 (where it is well-defined)
 and vCard (where it is less well-defined). Introducing yet another
 flavor of UID just leads to confusion, in particular when the same
 contact has both the original vCard UID and a local backend UID.

Yep, that would be a LUID (Local UID)


___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] UID in vCard

2011-11-14 Thread Adam Tauno Williams
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 other backends? Or are some unable to store
   the UID and look up contacts (efficiently) by it? In that case we will
   have to relax the semantic of the API and accept that some backends
   still use their own local ID. Supports UID should be defined as a
   capability of the backend so that clients can take it into account.
  I wouldn't call it local UID, it's rather backend's UID
 I wouldn't use the term UID at all for this local (or backend) ID. UID
 has a specific meaning for both iCalendar 2.0 (where it is well-defined)
 and vCard (where it is less well-defined). Introducing yet another
 flavor of UID just leads to confusion, in particular when the same
 contact has both the original vCard UID and a local backend UID.

Yep, that would be a LUID (Local UID)

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] UID in vCard

2011-11-14 Thread Milan Crha
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 the WebDAV
backend, and it generates its own UID too, and it also can download just
added contact from the server. It use eTag value as a revision value.

 And what does that mean for the file backend? I still think it would be
 good if the file backend supported creator-assigned UIDs. That other
 backends can't do that doesn't mean that file backend is not allowed to
 do it, right?

Sure, file backend can preserve already set UID.

  For example with Google calendar, which is served by CalDAV backend, the
  backend fetches newly added event from the server only to present UI
  with real object from the server, because the server can modify the
  event on its own when creating it (it adds default alarms, if set in
  Google's calendar preferences on the Web).
 
 Are you saying that Google Calendar EDS does *not* report the original
 iCalendar 2.0 UID?

Nope, I'm not saying that. Note the Google calendar in EDS means CalDAV.
The CalDAV backend doesn't change UID at all, it sets it only if the
component to be created doesn't contain it. And it also claims an error
when you try to create an object with UID which already exists. It's the
desired behavior you are looking for with the file backend, if I got
your request right.
Bye,
Milan

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers