[Kolab-devel] SPL for Kolab Webinterface

Bernhard Reiter bernhard at intevation.de
Fri Oct 13 19:01:16 CEST 2006


Raphael wrote on 05.10.2006:
> I would like to suggest an alternative approach to the 
> missing-webinterface-issue.

[I am opening a new thread for this.]

> For about two weeks now I've been thinking of writing a new Kolab2 
> webinterface from scratch with modern technology. I assume that this is less 
> work than fixing and integrating horde. 
> On the other hand I don't mind at all  
> if horde gets fixed and improved to work with kolab even if we end up with 
> two webinterfaces.

This is a viewpoint that many Kolab developers share.

Though, the effort of writing writing a new webinterface is usually
underestimated. And there are a few pitfalls.


> So this is the very-short-version of my proposal:
> 
> * Design and implement a kolab2 webinterface for all groupware things not 
> covered by today's webmail interfaces (squirrelmail supports IMAP, SMTP and 
> LDAP addressbook already for example).

Note that from the technological point of view 
email (for invitations) is tighly coupled to the calendering and the contacts.

> * In a second step this webinterface can be extended to also support email 
of 
> course.
> 
> * The technology to use would be the SPL scripting language[1]. The reasons 
> are that this scripting language feels more like a real programming language 
> (compared to purely-weboriented programming languages such as PHP), has 
> support for AJAX / Web 2.0 / RIA already built-in (!) and thus interactive 
> web-applications can easily be built with SPL (other features see link 
> below).
> Sessions are also stateful, the current status of the program including 
> dynamically allocated objects are automatically dumped and restored in 
> accordance with user-interaction. Thus all IMAP data does not need to be 
> fetched all-over again all the time (I do not know how (if) horde does 
> caching at the moment).


I know SPL as Clifford showed it to me last year in Vienna.
Martin also took a look.

There are several dangers in using SPL as far as we could see:

a) it might not scale for many parallel connectsion.
One question that was left was how often the state of the virtual machine
will be dumped. For each page request?

b) Usually someone would try to share the development offer with others
and the community around SPL might not grow as strong, this also means
less libraries you can use. One of my favourite language, Python
would have quite a few libraries which we could potentially use.

> The company I work for[3] would be interested in writing such a webinterface
> for Kolab2. Because of the modern technology that is available with SPL we 
> expect that it can be finished within reasonable time. We do need at least 
> some financial support to be able to develop such an interface. If you are 
> interested please get in touch with me.

I am interested to know about your estimations.
The Kolab-Konsortium is seeking funding itself for several nice improvements
to the solution, but we also talk to people that possibly might have
funding for a websolution.

> Our company has some customers that run Kolab2 and I have previously 
submitted 
> bug reports and fixes to the kolab project (last winter, and NetBSD support 
> just recently[4]). We generally intend to be supportive to the Kolab 
project.

Thanks again for these contributions.
Best,
Bernhard

> [1] http://www.clifford.at/spl/
> [2] http://www.clifford.at/spl/splpoker/  <-- Use Firefox with this
> [3] http://www.activenet.at  <-- the website _is_ very simple, I know
> [4] http://raphael.g-system.at/tech/kolab/
-- 
Managing Director - Owner, www.intevation.net       (Free Software Company)
Germany Coordinator, fsfeurope.org       (Non-Profit Org for Free Software)
www.kolab-konsortium.com   (Email/Groupware Solution, Professional Service)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1310 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20061013/8da9b2a3/attachment.p7s>


More information about the devel mailing list