Stefano Debenedetti wrote:
two things I'd like to see and I am willing to help for in the admin interface:
- syncronous interface
James is already a wonderful asyncronous framework, it would become wildly more powerful if a synchronous/transactional api was mapped onto its inner workings, it could mean making not only its setup (the users) but all of its behavior (the mailet pipe) modifiable at run-time. I mean: it's straightforward to have an asynchronous interface to James, just write a mailet that maps what it receives to some or all of the actions performed by the Remotemanager (I have done it myself and can send the code if anybody's interested) but, apart from the security issues here, it would be much more useful if for the remote operator it was easy to know if an operation succeded in a transactional sense i.e. so that I can assume the user was created if and only if I get a return value out of a method (as opposed to settling down to wait for the answer message or mail), don't know JMS so to acheive this may be either straightforward or need some glue...
- max interoperability
how easily can you export a JMS interface as a web service? Again, can't answer that question myself.. I'd like to see the admin interface exported as SOAP (using the Apache toolkit? or maybe even some simpler XML-RPC?) and then the various GUIs written on top of that (the telnet/ssh wouldn't need to change much but most importantly one or many web interfaces would be immediately available just by styling the XML with CSS or XSL, it could also work with XForms..). Writing other kinds of clients could then be done in languages that make ui creation easier and less resource-hungry than java.. making James the ultimate interoperability framework (it already is, just finished effortlessly porting my mail app from windoze to freebsd :)
Synchronous certainly required for a useful user interface. Transactional is another matter. SOAP won't be entirely simple to get running inside of JAMES. SOAP over HTTP would mean hooking in a servlet container. SOAP over SMTP is a better fit with JAMES (and is likely to find support in the developer community, if past comments are anything to go by) but probably useful for this purpose. It would be inherently asynchronous. I know nothing about JMX, so I can't comment on how that might help (or not).
I suspect that the approach to take in order to use SOAP/XML-RPC would be along the lines of:
1. Expose the necessary JAMES APIs so that they can be called by an internal "manager" component. I think that this has already been done for the rmi remote manager.
2. Implement a component that calls thes APIs and exposes them by whatever means you desire (in this case, SOAP). This could possibly be through a tomcat instance modified to run in avalon and running SOAP servlet (maybe using axis) that then called the JAMES API's exposed in step 1.
3. Create a user interface that uses SOAP to talk to the servlet you've just embedded.
As you will see, this is unlikely to be a simple undertaking. I suspect that the quickest way to get something working would be to run with the rmi-remote proposal.
If you are interested in developing this, perhaps you should bring this discussion over the james-dev?
Cheers
ADK
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
