james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anne S <hyperfl...@gmail.com>
Subject Re: Proposal for Web Admin Console
Date Thu, 16 Jun 2005 22:45:26 GMT
Hi Juan,

Thanks for the interest, and the outline. Here's some ideas I was
throwing around:

Embed Tomcat - I'm vacillating on the Tomcat issue. I think the
highest goal would just to write the admin interface, but not make it
Tomcat specific. I use Tomcat personally for my web site, but I don't
want to force end users to use Tomcat if they don't want to. There are
several other servlet containers out there with perfectly good
developer communities (WebSphere for example,
http://www-306.ibm.com/software/websphere/), and although I haven't
tried them out personally, there's no reason why a program that runs
in Tomcat can't run in other containers.

Plus, the James team might not be too happy dealing with embedded
Tomcat. Including that in a James distribution, IMHO, simply increases
the number of potential holes for a minimal benefit. If it's
absolutely necessary, we can create a SourceForge project combining
admin interface + Tomcat + James, and market it as a one stop
developer's solution good for development purposes, ala IndigoPerl,
which combines Apache+PHP+Perl in a easy-to-install package.

Decoupled: Yes, definitely decouple the admin interface from James. I
don't want hooks to go too deep into James, because then if the
configuration method changes, it's that much harder to rewrite. For
the communication system, I was envisioning a wrappers around both the
Remote Admin Interface and config.xml. The config.xml would just be
manipulated directly (write and read XML) and the Remote Interface
would be "spoken to" through the regular method, telnet to port 4555.

Framework: I was just going to write a framework from scratch, but if
you feel strongly about reusing another framework, then suggest it and
we can explore if it's right for our needs. Java, of course, is the
preferred language, keeping with the theme of 100% Java in James and

Site Navigation & Layout: I was going to follow the general design
layout of other admin interfaces, such as CPanel, Plesk, phpmyadmin,
etc. I was thinking of perhaps bugging a graphic artist to design a
symbol of a mail truck plus postman, then writing on the bottom:
"James Email: Where To?" or "James Server: How Can I Be Of Service?",
something witty and friendly at the same time.

Clustering: As for clustering, I'm not the person for that. I
understand the James-HA project on SourceForge has code that can
cluster James, but I haven't tried it, nor do I know anybody who runs
clustered James in a production environment. I believe there are some
SOC projects that have suggested clustering, so if they can do
something about that, I'd be more than happy to add a module to the
admin interface permitting cluster management.

Another thing I wanted to put on the table was: Do we want to require
anything more than James +  Tomcat servers for the admin interface? Do
we, for example, want to require a db of some sort to handle temporary
state data? One thing that has been bugging me is that an admin
interface requires some way to keep state, especially if Wizards are
going to be implemented. Flat text files have the locking problem. A
DB allows us to concentrate on the data manipulation aspect and not
worry about having to store it. We might even be able to embed IBM's
Cloudscape Java DB into the admin interface. (What is Cloudscape
called now? When IBM donated it to Apache, I believe that they changed
the name. Derby, wasn't it?)

That's about the end of my thoughts. I'd like to hear anybody else
chime in on the subject. Thanks.

To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message