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

List:       kde-pim
Subject:    CDO (Collaboration Data Objects)
From:       Don Sanders <dsanders () cch ! com ! au>
Date:       1999-07-12 9:50:30
[Download RAW message or body]

I have been reading about Microsoft's CDO. This is the set of interfaces
provided so that developers can access and manipulate Outlook (MS PIM)
information. I found it interesting as it reveals (a little) about how MS solved
several problems we have been talking about.

Basically as far as i can tell there system works like this.
A Session object is created and used to logon to a  MAPI (messaging)
server (possibly a remote one?). From here you can access folders such as the
inbox and outbox folders. Folders may contain folders and messages. A message is
usually an e-mail, there are methods for getting the subject and attachments
etc. of a message. 

The Session object can also be used to access an addresslists object which
is a list of addressbooks. Each addressbook has an addressEntries member which
returns a list of addressEntry. An addressEntry is normally an addressbook
entry, if has a fields and an a id member and an update method etc. Apparently
an addressEntry can also be a distribution list which I guess is a list of
addresses. I guess address book folders aren't supported.

The Session object also contains a GetInfoStore method which returns an
InfoStore which is used to access the folder hierarchy of messages (just
messages not other data types?).

A Session object also has a GetDefaultFolder method which provides
another way of getting to the inbox and outbox folder and also a way of getting
the Contact, Calendar, Journal, Notes, Tasks and SentItems folders. (Hmm you
know the addressBook and the Contact folder seem to be different things, I'm
pretty sure that's a screw up on MS' part, we should just ignore the
addressbook completely I think it is a premature version of the contacts
folder, except the addressbook supports lists of addresses and the contact
folder doesn't).

Apart from that MessageFilter and AddressEntryFilter objects are provided for
searching.

Here are some references:

CDO Library Object Design:
http://msdn.microsoft.com/library/sdkdoc/cdo/oleoview_7vvy.htm

Programming Tasks:
http://msdn.microsoft.com/library/sdkdoc/cdo/oletasks_4ofn.htm

What can outlook do for me? (Dated but nice introduction graphic)
http://www.microsoft.com/outlookdev/articles/movs105.htm

I'm interested in seeing how LDAP compares to this (more reading requires
and I know it's not the same thing). I think LDAP seems very promising for
remote servers but are wondering if it is overkill for local stores. 

I like the MS method of using a Session object to log on. But don't see why
there can't just be one getFolder method for getting a list of folders or
getting (a possibly default) folder in particular. I think folders themselves
should be homogeous, that is they should contain one type of entry. Openpart
viewing objects should be defined for viewing a list of each type of entry.

(I'm still not planning on implementing anything just browsing).

> > 1) I wonder how similar this is to the problems  LDAP addresses. Actually it
> > would be pretty cool if the pim could provide views of infobases (not really
> > sure if that's the right word) accessed via a LDAP server. LDAP looks
> > interesting. (Note I'm just saying this would be cool and we shouldn't do
> > anything to make this very difficult in the future but I have no intention of
> > doing the work to make this a reality at the moment)
> 
> Me neither. I've read through the various LDAP RFCs now and I'm not about to
> start implementing any of that. It's certainly something to have at the back of
> our minds though - there are plenty of LDAP-interfacing projects going on.
> OpenLDAP looks like it may be useful to us. The license appears to allow us to
> use code too.
> 

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