[Kolab-devel] python connector - preliminary ideas

[Gunnar Wrobel]

Dick Kniep <dick.kniep at lindix.nl> writes:

> I would like to elaborate a little on the functionality:
> Connect to kolab:
> Off course we need a host, and a userid. Then we have authentication (SASL) 
> and encryption with TLS. Do we need a password to sign on? If yes, is there a 
> way to provide that password without compromising security?

I assume that the basic use case for the library would be that it is
called by providing a given USER/PASS combination. This should usually
not be the admin of the system.

The connection process to Kolab for user USER with password PASS
basically comprises of the following steps:

- Connect anonymously to the Kolab LDAP server, search for USER and
  identify the HOMESERVER for USER

- Connect to IMAP on HOMESERVER as USER with PASS

Both connection procedures would be handled through a LDAP library and
an IMAP library. Both libraries should handle the main workload for
getting a secure connection. I don't think there will be much more
than telling the lib to try secure first and use insecure if secure
does not work and insecure was allowed.

> Processing of acl
> I presume ACL's are stored on the server, and so could be retrieved, allowing 
> the calling program to know what authority the user has, and thus adjusting 
> its presentation. The result could be a list of objects of persons on the 
> system. 

ACL's are fully handled by the IMAP server. Once you logged in as USER
the cyrus IMAP server will only present you with the mail folders USER
actually has access to. The question here would be if the library
should support modifying the permissions on the folders USER has
access to.

Things like showing the user the other users on the system could be
provided if the library uses the Kolab LDAP server. But I would not
consider this type of functionality to be in the central part of the
library.

> Retrieve entries
> As a default one retrieves the stores from oneself ( = the user that is logged 
> on). However, if one wants the calendar of a certain person, one could simply 
> use the object retrieved in acl, and retrieve the calendar for that object.

Kolab stores the groupware objects (events, contacts, tasks etc.)
attached to email messages in IMAP folders. Since the IMAP server
fully handles the access control to each folder USER will
automatically have access to all his/her own folders as well as all
folders he or she has been given permission to view.

So if I am USER_ONE and use the library to connect to the IMAP server
I won't be able to see the calendar of USER_TWO. Only if USER_TWO
explicitely set the IMAP acls on one of his/her calendar folders so
that USER_ONE can see this folder.

This type of calendar synchronization is usually done via free/busy
lists that contain reduced information as compared to the real events
in the IMAP folders.

I don't think the library should provide capabilities to integrate
calendars over several users.

> As far As I understand, there are 4 main stores that can be retrieved, called 
> "Calendar", "Contacts", "Tasks" and "Journal". These can have different names 
> (depending on language and user intervention) and could be distinguished by 
> annotations which is available in Python 2.5. (I do read this discussion;-))
> The layout of the stores is described in the kolab documentation and can be 
> parsed with elementtree.

The "stores" are IMAP folders. Each folder can have a type
annotation. The type can identify a folder as a special groupware
folder. In that case the email messages within the folder should hold
attachments with Kolab XML files. These files represent the groupware
objects and can be parsed using elementtree.

> Caching
> Now here I have a problem. I don't like caches because they make life 
> complicated. As a programmer you always have to make sure that caches get 
> synchronized. I can understand that this can be required in certain 
> conditions, but in many situations (within a LAN or so) it is not required. 
> So my question is "Do we need a cache???" If we REALLY want  caches, can we 
> implement them in such a way that they can be omitted?

Yes we want caching :) But I do believe that it does not hurt to get
the basic functionality of the library without caching first. If the
structure is good enough the cache will be just an additional layer
that provides the same interface to the calling program as the bare
library without caching.

> - XML processing, I would prefer elementtree as it is much faster than pyxml 
> and much more pythonic (= easy to use)

+1 on elementtree


> Shouldn't we first decide on the functionality?
> - Connect to the Kolab server, encryption
> - processing of acl
> - Retrieve entries
> - Cache kolab results
> - Update entries

Just as a summary:

I believe that connecting to the Kolab server, encryption, processing
acl as well as retrieving messages would all be part of

- IMAP handling

Retrieving/Updating entries could then also be one combined class that
is concerned with

- Kolab groupware object/XML handling

Finally a 

- Cache

is needed though I am not certain whether this cache is better as a
pure IMAP cache or a cache that even wraps around the XML handler
too. How is that done for the current clients that implement caching? 

Everthing besides that (LDAP, free/busy...) would be something I'd
consider additional and not central to the lib.

My .02 cents. Some of it will be wrong but I know there are some
experienced kolab devs around here that will correct me :)

Cheers,

Gunnar


-- 
____ http://www.pardus.de _________________ http://gunnarwrobel.de _

E-mail : wrobel at pardus.de                          Dr. Gunnar Wrobel
Tel.   : +49 40 432 72335                      Hartwig-Hesse Str. 12
Fax    : +49 40 432 70855                            D-20257 Hamburg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  >> Mail at ease - Kolab out of the box <<                 P at rdus
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~