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 Tomcat. 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
