[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] Attendees
From:       Mark Westcott <mark () houseoffish ! org>
Date:       2001-12-27 20:17:00
[Download RAW message or body]

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, as 
these are by definition unique.  Not using a UID just creates the possiblity 
for things to go wrong entirely unnecessarily.  I had a quick look through a 
(used) 800 contact database, and names are replicated, and further more there 
are many names without email addresses.  


> > 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.  
Again, I disagree that it would not be a good idea to use the X-Parameter 
notation.  Interoperability is not a concern at all here - these field merely 
stores the kabc UID of the contact so that the user can 'hyperlink' to their 
kaddressbook entry.  There would be no reason for any other application to 
need to access/edit this information.  I accepted the interoperability 
problem with my last implementation, but here no 'important' information is 
stored in the field like last time.  As regards to other applications opening 
the file and the entry getting lost - firstly, it would not really matter, as 
this information is far from vital.  Secondly, I wonder how often people 
actually open up their .ics file in other applications?

All being well, I'll submit a patch shortly (its pretty much done) - the patch 
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/
[prev in list] [next in list] [prev in thread] [next in thread]