Oh no, I realise the pain; but then if the OS had common objects, contact, address, telephone number, file metadata, calendar entry and you could register extensions ... like ... oh .... Active Directory .... and handlers for protocols like .... IE ....Larry Osterman said:Who gets to define the schema for a "contact"? How about a "document"?blowdart said:*snip*
Once you start thinking in those terms, you realize quite quickly that the idea of abstract "objects" can quickly become unworkable. That's because Outlook's idea of what belongs in a contact object might be very different from Windows Mail's idea, which might be very different from Thunderbird's idea.
Here's a really simple example: To Outlook, an email address is a multivalued string property which lists all the possible email addresses for a particular recipient (there could be a dozen or so of them depending on the topology of your network). To Windows Mail, an email address would be just an SMPT address. To the email system I wrote back in high school, it's a RSTS-E account name ([<octal value>,<octal value>], to something else, it might be something totally different, with a totally different syntax.
Now consider what happens when you use a contact in Outlook that was created by my high school email program?. Outlook doesn't know how to send email to this contact, it doesn't even know how to interpret the address.
Can you guarantee that all clients of this object store all handle these cases properly?
This is just one small example of the kinds of interoperability problems you can get - this one is probably solvable, but there are others that aren't.
Meh, you get the point.