Noel J. Bergman wrote:
I'm just not sure what, if anything, to take away from your comments regarding what we need to do in terms of James v3 design and implementation.I'm not sure what point(s) you're making, in the context of James. This1. stop being paranoid about dependencies 2. think about users and what they want 3. containers are about delivering value to users 4. there is a lot of scope that we can deal with 5. most of that scope is a container concern 6. if the spec if good then containment solution will be transparent 7. transparence isn't so easy 8. I'm willing and able to contribute to the work 9. just wanted to have more than eight points
isn't a discussion about an Avalon container.
I'm not talking about Avalon containers. I'm talking about the Mailet API.
The current Mailet API provides a non-dependent interface. That's fine but when we consider logging, configuration, dependency management, etc. you are talking about mailet architecture - stuff that may not be expressed in the Mailet interface but would be expressed in a Mailet Architecture Specification. The Specification would/should/could include the specification of the container side of the contract - i.e. what assumptions can a Mailet author make and what obligations is a Mailet container author required to handle.We have domain specific needs regarding a user data model and message storage model. Those are key services provided to the protocol handlers, matchers and mailets. And those, in turn, implement the messaging server. I don't care which container we're operating in. And people seem fairly firm regarding a Mailet API that works well within an Avalon container, but is not tied to requiring one.
The reason why I'm thinking about these issues is that I have some application scenarios that deal with close integration of business logic into a messaging environment. I'm looking at the James system as a platform into which I would be able to dynamically add and remove mailets based on higher level components that are managing the James system. At the other end of the spectrum I know I'll have to deal with mailets that have complex dependencies which means either plugging in mailet load management into James, or, building the mailet and supplying the mailet instance to James.
I don't have a good idea of what assumptions are being made on the V3 definition - but as I mentioned above - I do think we need mechanisms that will allow the introduction of rich-Mailet. This means addressing things like I've described above.
I guess this is drawing the distinction between:
* the Mailet service interface (the minimal non-dependent Mailet API)
* the Mailet construction model (the aspects dealing with mailet
logging, configuration, composition, etc.)
Cheers, Steve.
--
Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
