From kde-pim Thu Dec 27 20:17:00 2001 From: Mark Westcott Date: Thu, 27 Dec 2001 20:17:00 +0000 To: kde-pim Subject: Re: [Kde-pim] Attendees X-MARC-Message: https://marc.info/?l=kde-pim&m=100948410807910 On Wednesday 26 December 2001 10:54 pm, Cornelius Schumacher wrote: > On Friday 21 December 2001 11:39, Mark Westcott wrote: > > After some thought I have decided to redo my 'Contact Pinning' > > feature using Attendees (which is turning out to be a lot easier). > > Sounds good :-) > > > What I'd like to do, is store the UID of the attendee along with > > their name/email address. This is much better than doing a > > findByName lookup to find them from their name as there could be two > > or more contacts with the same name. > > The email address tends to be a better identifier, and email address > combined with the name is as reliable as the UID. I have to disagree with you here. Nothing can be as reliable as a UID, a= s=20 these are by definition unique. Not using a UID just creates the possibl= ity=20 for things to go wrong entirely unnecessarily. I had a quick look throug= h a=20 (used) 800 contact database, and names are replicated, and further more t= here=20 are many names without email addresses. =20 > > Is there room in the iCAL specifications to store extra data along > > with the attendee? If so, whats the field name? > > It's possible with the "X-something" notation for custom parameters > (see rfc2445 for details). libkcal currently doesn't support this, but > it wouldn't be a big problem to implement it. In most cases it's not > the best idea to use such custom properties, because this data isn't > understood by other applications. It might even get lost just by > opening the file in an application not supporting the custom entries > (which is a bug, but happens in reality). Well, I already found and implemented this before I received your email. = =20 Again, I disagree that it would not be a good idea to use the X-Parameter= =20 notation. Interoperability is not a concern at all here - these field me= rely=20 stores the kabc UID of the contact so that the user can 'hyperlink' to th= eir=20 kaddressbook entry. There would be no reason for any other application t= o=20 need to access/edit this information. I accepted the interoperability=20 problem with my last implementation, but here no 'important' information = is=20 stored in the field like last time. As regards to other applications ope= ning=20 the file and the entry getting lost - firstly, it would not really matter= , as=20 this information is far from vital. Secondly, I wonder how often people=20 actually open up their .ics file in other applications? All being well, I'll submit a patch shortly (its pretty much done) - the = patch=20 is to kaddressbook, libkcal and korganizer. Many thanks, Mark _______________________________________________ kde-pim mailing list kde-pim@mail.kde.org http://mail.kde.org/mailman/listinfo/kde-pim kde-pim home page at http://pim.kde.org/