[Kolab-devel] python connector - preliminary ideas

[Dick Kniep]

Hi Pythokolabonistas,

My 2 cents in this discussion, I know a lot about Python, nothing of twisted, 
a little of imap, and a little of kolab. So please be gentle if the points I 
put forward seem ignorant. So here goes.

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

And yes there should be an "import kolab"

Next we could decide on the technical issues
- Twisted versus standard python imap
- XML processing, I would prefer elementtree as it is much faster than pyxml 
and much more pythonic (= easy to use)
- other alternatives.

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?

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. 

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.

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.

Here I think there will be many functions that can be added to make life easy 
for the receiving program like searching for appointments, searching for a 
person etc.

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?

Update entries
I would like the interface as pythonic as possible, so fill an object with 
fields, and next say something like "Store" and then it should be transfered 
to kolab. (I know this is oversimplified)

Op vrijdag 1 december 2006 19:19, schreef Gunnar Wrobel:
> Torsten Irländer <torsten.irlaender at intevation.de> writes:
> > On Friday, 1. December 2006 15:05, Stéphane Konstantaropoulos wrote:
> >> Hi All,
> >>
> >> This is more loud talk than actual design.
> >>
> >> Python has the imaplib library that allow to access almost all the
> >> features of IMAP4rev1. However it does not have any object oriented way
> >> of directly accessing messages.
> >>
> >> A little problem there is that the annotations are supported only from
> >> Python 2.5, we could check for the version and if it's an older version
> >> we are running we could just use the standard names ("Calendar",
> >> "Contacts", "Tasks" and "Journal").
> >
> > Well I am far away from beeing an expert on this, but it might be an idea
> > to take a look on the twisted library which provides nice imap
> > functionality too and combines this with an elegant way of writing
> > asyncronous network applications which might become handy. The drawback
> > of this approach is to introduce another library.
> > Anyway, I do not know if twisted is of any benefit for this connector but
> > I wanted to throw another idea into this discussion.
>
> The only problem with the twisted IMAP library is also missing
> functionality. It lacks the acl handling as well as the annotation
> handling.
>
> Other than that it's pretty nice. It uses zope.interfaces which is a
> big plus in terms of being object oriented. It provides nice client
> and message objects. And this might make it far easier to code a
> caching wrapper around the IMAP part.
>
> I believe the missing functionality should not be too much of a
> problem since the Twisted classes in general are not too hard to
> extend.
>
> If people would choose this lib as the imap handler I would definitely
> offer to get involved there since I already did some twisted
> programming and like the concepts behind it.
>
> Cheers,
>
> Gunnar

-- 
Met vriendelijke groet,

Dick Kniep
Lindix bv
De Specerij 30
1313 NE  Almere
tel. 036-521 5580
fax. 036-844 1825