[dev] What should we do about GUIDs changing?

[Marcus I. Ryan]

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.

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.

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., and can generate a
reasonably reliable GUID in PHP, according to http://us4.php.net/uniqid, with
md5(uniqid(rand(), true)).  Not sure what the md5 does to its global
uniqueness, but that's what the site suggested.

The bigger question is still how we use and store them.  I can think of at
least three options for handling GUIDs

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

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

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

I'm not sure what the best answer is, but as long as I'm not coding it, I of
course prefer #3 for the flexibility ;)  The other reason it doesn't seem
excessive is we will already have to implement a similar scheme for SyncML
which requires we maintain a table like that mapping our local item ids to
remote item ids (not necessarily guids).

So those are my thoughts...do with them what you will. :)

--
Marcus I. Ryan, marcus at horde.org
-----------------------------------------------------------------------
  "Love is a snowmobile racing across the tundra and then suddenly it
  flips over, pinning you underneath.  At night, the ice weasels come."
                  -- Matt Groening
-----------------------------------------------------------------------


Quoting Chuck Hagenbuch <chuck at horde.org>:

> We've started using GUIDs (generic universal ids or somesuch) to refer to
> various objects throughout Horde (tasks, notes, etc.) for purposes of 
> external
> references (iCalendar files have a GUID for each vevent) and for syncing
> support.
>
> However, the way we have them generated right now for most apps is something
> like this:
>
> appname:sharename:itemid
>
> sharename is the problem there - what if the user moves a task to a different
> tasklist? We *should* be smart enough to still be able to see it's the same
> task when we next sync, etc.
>
> So, any ideas on a better way to do this? Should we add an extra 
> field for it to
> all our data stores? I'd rather not, where we can avoid it.
>
> One idea: use the task_id directly and leave the sharename out. We 
> could do this
> in nag because the task_id will either be a unique id in the nag_tasks table,
> or a category_id, which will be unique across all tasklists. Though, 
> it occurs
> to me that the way the code is written, we delete and recreate the 
> task when we
> move it between tasklists, so that'd have to be fixed too.
>
> Other suggestions?
>
> -chuck
>
> --
> "Regard my poor demoralized mule!" - Juan Valdez
> --
> Horde developers mailing list - Join the hunt: http://horde.org/bounties/
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: dev-unsubscribe at lists.horde.org