[OGo-Evolution] designing new version of ex2ogo

[Erik Romijn]

Hello,

we've been thinking about the future of ex2ogo. Basically we came to the
conclusion that the current ex2ogo is a bunch of unreadable and
unmaintainable code.

Therefore we are starting a new effort with a better design, using the
knowledge gathered in ex2ogo-0.1. Ofcourse this will also be GPL
licensed.

We're going to do things more the object oriented programming way,
although we use this as a tool and a guide and not something we have to
conform to.

The current ex2ogo is mostly built on ugly regular expressions and other
similar mangling. The new ex2ogo will not mangle anything directly.

As the new ex2ogo will cache all data there will three distinct events:
- item(s) are saved to zidestore
- item(s) are retrieved from zidestore
- item(s) are requested by evolution

We designed the classes ZideStore, Connector, Request, Response, Item
(extended by Calendar, Contact etc.) and ItemList (extended by
CalendarList etc.).

The idea is that when ex2ogo is ready to process a new request it asks
the Connector object for a new request. This will deliver a Request
object, which states what needs to be returned in what range. A simple
cache lookup can be done returning an ItemList (this can be
CalendarList/ContactList/EnterpriseList/TaskList objects, but they all
have the same interface) that contains all the matching Item objects
(can be Calendar/Contact/..). This is given back to the Connector which
then can send the data to exchange.

For retrieving the data from ZideStore things are similar. A Request
object is made that describes what objects we need. The Request object
is sent to the ZideStore object through which we can then retrieve a
Response object containing an ItemList.

Seems a bit complicated, but in the end we think it will make things
much more transparent.

And we thought of something even better - one could build a Connector
object with the same interface that does not listen on a socket for
incoming WebDAV, but that directly communicates with Evolution.
It's also possible to put a connector for any other groupware client.
The Calendar/Task/.. objects will be modelled after the properties OGo
keeps, so any conversion would be done by the Connector object.

One thing that you may notice is missing is the possibility of OGo to
have more than 1 place where Contacts are stored. To keep user interface
simple our ZideStore class will flatten this out to 1 folder with
contacts.
However, it is possible to modify this and keep several ContactList
objects.

I have built a class diagram showing the basics of what we plan to do:
http://oracle.toltech.nl/~erik/ex2ogo_class_diagram.png

Feel free to hail/bash/comment on my ideas :)

greets,
Erik Romijn