[dev] What should we do about GUIDs changing?

[Chuck Hagenbuch]

Quoting "Marcus I. Ryan" <marcus at horde.org>:

> GUID is actually globally unique identifier.  I'd be inclined to move (back?)
> to a more globally unique identfier so it will be unique not only on our
> system but on anyone else's system as well.

There's no back; what we have now is vastly more unique than anything we had
previously.

We can also add @$conf['server']['name'] to the GUIDs if we're really 
concerned
about them being unique across multiple servers. Not sure at this point 
if that
makes a difference if we're using md5(uniqid()) or whatever, or if it's a good
idea.

> I don't know that anything that really requires a genuine guid as of now, but
> it could potentially avoid problems in the future, or allow new
> functionality.  One thought is adding a "reference" event to a shared
> calendar that points to a master event by guid; even if the master event is
> moved, changed, relocated, etc., the reference should still be able to find
> it.

Cool idea. I'd love to see a patch. ;)

> So I would like to see us generate a genuine guid.  We won't use it except in
> code, I would assume (like any other guid), so readability is not that big of
> a deal.  We've used md5 hashes before as event ids, etc.,

Eh? When?

> (1) Make it the eventid/taskid/noteid/whatever.  Since the generated guid
> should be unique even across multiple installations, it doesn't rely on the
> hierarchy for uniqueness, so moving between shares, etc., shouldn't cause a
> problem.

I'd like to do this wherever possible. Much simpler.

> (2) Make it a new field in the backend database (seems a little redundant as
> we don't really count on the eventid to be sequential or anything (at least
> some used to be md5 hashes; I don't remember off-hand the reason for changing
> that).

I still don't know what hashes you're referring to. :) We still use them for
object_id in Turba, and nowhere else...

> (3) Add a new class or use an existing class (History? Links?) to 
> store a guid
> for an object outside the backend it uses.  One place I see this as important
> is in Turba where we may not have an option of adding a guid field, or we
> don't currently have such a field defined/required.  Similarly, if we require
> such a field in the backend we may unintentionally limit the backends we can
> make available in any given app.  Of course, separating the guid from the
> backend allows more flexibility but at the cost of complexity and
> maintenance.

It could be History, but maintaining it would be a royal pain. We can do this
for LDAP in Turba, etc., if we really need to, but since we can tackle this on
an app-by-app basis (or driver-by-driver, with getGUID() and makeKey(), etc.),
I'm not going to worry about it now.

-chuck

--
"Regard my poor demoralized mule!" - Juan Valdez