[dev] Re: iCal spec for UID values - persistence question

[Jan Schneider]

Zitat von Kevin Myer <kevin_myer at iu13.org>:

> http://bugs.horde.org/ticket/?id=1107 was a bug I filed awhile back.  Chuck
> thinks the current code works correctly but I still think my original report
> captures the essence of a problem with the way Kronolith generates UIDs for
> events.  Now that got me thinking to other similar cases, where 
> Kronolith might
> start generating UIDs and that would occur in importing calendar data from an
> outside source.  That further led me to question whether or not UIDs 
> are unique
> to a system, or whether they are intended to be globally unique - 
> i.e., if you
> could export from one system, import to another, export from that and import
> back into the original and the UID would be the same.

UIDs are globally unique, in contrast to the internal event IDs we use 
in Kronolith, Turba, etc. too.

> I would think that if you have to persist something, that means you 
> have to keep
> it.

Yep.

> A quick test export from Kronolith into Apple's iCal showed me that either my
> interpratation was wrong, or Apple's interpretation was wrong.  When 
> the events
> came back out of iCal, they had Apple UID's (ironically enough, Apple appears
> to use the machine MAC address as part of the id...)  Importing a test event

It may be important *how* you get the iCalendar data into iCal (I 
really hate this name). Did you import iCalendar files, or did you 
subscribe to a Kronolith calendar through ics.php? I *might* consider 
it acceptable if they change the UID on import, because you don't 
really use the same calendar at that point anymore.

> So can anyone who knows the iCalendar spec better than I comment on 
> the state to
> which UIDs should persist?  Or has anyone worked with other iCalendar
> conforming application, and can test to see what happens to a UID for 
> an event
> that is imported and exported from the system?

I can't speak for other applications (does Sunbird support import of 
iCal *files*?) but from my commons sense I would keep the UIDs on 
import in my application. And IIUC, we do this in Kronolith.

> I'd think that Kronolith should maintain UIDs if they already exist, for both
> within Horde (which would fix my initial bug report of this) and for events
> generated from external systems (which would then allow me to 
> implement a poor
> man's type of sync to Apple's iCal, for offline access for certain staff
> members that don't have Internet connectivity most of the week - of course, I
> have to get Apple to use persistent UIDs too..)

Exactly.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/