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

List:       kde-pim
Subject:    Re: [Kde-pim] Attendees
From:       Cornelius Schumacher <schumacher () kde ! org>
Date:       2002-01-07 22:05:03
[Download RAW message or body]

On Thursday 27 December 2001 21:17, Mark Westcott wrote:
> On Wednesday 26 December 2001 10:54 pm, Cornelius Schumacher wrote:
> > On Friday 21 December 2001 11:39, Mark Westcott wrote:
> >
> > > 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.

The problem with unique IDs is that it's hard to assign them correctly. 
It's easy to create a unique ID, but what you want is to assign the 
same ID, if the entry is the same. That's not difficult if you stay on 
one system, but it's hard, if you have information for example coming 
per e-mail.

If you get an email from somebody and want to associate this with some 
existing contact information on your system you have to find out, which 
entry represents the sender of the email (by looking at the name and 
the email address, because there is no unique id in the email). So you 
need to do this lookup anyway and can't rely on the unique ID.

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

I agree that it's not a problem to store this information. But you have 
to provide a way to get this information without relying on the stored 
data anyway, so I don't see a need to save it in the file. Performance 
shouldn't be a big problem here, or is it? But if you want to store the 
UID in a custom parameter, that's ok with me (as long as you provide a 
decent implementation for this in libkcal ;-)

> Secondly, I wonder
> how often people actually open up their .ics file in other
> applications?

If you have activated the automatic saving in KOrganizer, you will lose 
all custom information, just by opening the file in KOrganizer. I know 
that's not nice, but up to now nobody has fixed this behaviour and 
nobody complained. So for example accidently starting a pre 3.0 version 
of KOrganizer can remove this information from your files. This may 
happen more often than never. :-)

> All being well, I'll submit a patch shortly (its pretty much done) -
> the patch is to kaddressbook, libkcal and korganizer.

Great. I'm looking forward to apply the patch to the code.

-- 
Cornelius Schumacher <schumacher@kde.org>
_______________________________________________
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]