[Kolab-devel] SPL for Kolab Webinterface

[Raphael Langerhorst]

Am Freitag, 13. Oktober 2006 19:01 schrieb Bernhard Reiter:
> 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.

I see. And it must be that way if horde is already being "somewhat" worked on 
for such a long time.

>
> > 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?

Apache is dumping it with every page request - not avoidable due to the apache 
architecture I suppose. SPL is using the CGI interface for this. But maybe in 
an extreme situation one could even patch apache specifically for this 
purpose.

On the other hand there is a standalone webspld available which preserves the 
sessions and does NOT dump for every page request. I guess this is the very 
reason why webspld exists at all (it is included in the SPl sources).

It would be possible to use webspld for the webclient

>
> 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.

This concern I share very much and it is also the reason why it has taken me 
quite some time to really consider SPL as an option.

>
> > 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.

Estimations are always tricky, but we expect to be able to create a useable 
webinterface until end of the year with a budget of 4000 EUR. Please note 
that it will only have primitive mail support (at least at the beginning, it 
can always be improved later).

I personally think that the web interface will then still require some more 
months of community work for bug fixing and working out rough edges. But 
the "bulk" work could be done within that budget.


Best Regards,
Raphael

PS: the original SPL poker link was broken, for some reason. I've now put up 
the splpoker example "application" at my personal site:
http://raphael.g-system.at/splpoker/

(note: splpoker will be removed again in a couple of months of course)


>
> > 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/

-- 
Raphael Langerhorst
http://raphael.g-system.at
PGP Fingerprint: FB70 E4F0 40EF 071B F266 40D4 32C6 A578 46C4 8559
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 478 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20061016/9e679585/attachment.sig>