I've been a little submerged at work lately so I haven't been able to
follow unicon news. I started at this job writing servlets in Java
under Tomcat. Why do I tell you this, you ask? Well, about two months
ago I decided that I would make my manager get the idea to re-implement
them as Apache modules. Because I wanted to learn the ins and outs of
Apache so I could work on... mod_unicon! (In the process I've also
messed around in the Apache internals.)
So when Clint told me yesterday that mod_unicon was being discussed on
the list... Coincidence? I THINK NOT!
Ok, jokes aside: some good points have been raised about a socket server
written as an app server. Points have also been raised about how big
and ugly mod_perl is, and how useless the O'Reilly book is since it
only talks about mod_perl, neglecting modules written in C. I agree with
all that.
However, I think mod_perl is ugly and huge because it tries to mirror
the Apache module API exactly. That is a serious mistake. What we should
do is think about what the interface *should* be for a web app to be
written in Unicon. Then we figure out what the best way to implement it
is.
I have also been writing modules for the Netscape server so I have seen
(and written code for) two rather different APIs. I have some ideas about
what a Unicon web app needs to do, but I'd like to hear others' opinions
without them being polluted by my prejudices.
(One thing I will say: if we decide that an Apache module is the way to
go, then a DSO is easy to do, and is the easiest for a non-expert to
install. A DSO is a .so on Unix and a .dll on Windows.)
I do have some code written for mod_unicon, but I'm not going to say
anything about it, because I want to be able to throw it away if we
decide to do something else.
-s
_______________________________________________
Unicon-group mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/unicon-group
