Nicola Ken Barozzi wrote:
I was thinking today, that I understood that you see Avalon as a utility system, not a service or component framework. For me mailets are services and components, this is why I see Avalon in them. It's natural.<tangent type="realization">
This is an interesting point, and this really helps me reset my expectations of Avalon. I have always viewed Avalon as a server platform, hence was bothered that it didn't have convenient/solid logging, usable error messages on configuration problems, no service installation feature, and etc... I would call it just a design-pattern enforcement system (obviously a loaded term).
But what Nicola says makes it much clearer to me... my expectations are off-base, and the Avalon community IS looking at this project as primarily a way to make the IoC design pattern much easier to implement and use. Like it even says on the home page, "a set of components for applications written using the Java language," nothing particular about a generic server platform.
Anyway, complete tangent, but this was a great point to reset my expectations of what Avalon is. Thanks.
</tangent>
Then why not make mailets *extend* the servlet spec? Even if not in code, if it's not feasable, at least in practices. IE: How is this done with servlets? Ok, do it with mailets too! Like config, logging and all that stuff.Ironically, this is what some guys at java.apache.org proposed long ago before my original (ugly) code donation. The servlet group rejected it then largely because servlets (HTTP) is a request/response model while mailets (SMTP) are a filtering/queuing/messaging model. So the fundamental service() API really didn't mix well, but we kept the intention of trying to be similar otherwise (part of why we called them mailets). You'll see many of the same design (flaws and others) in the mailet API that are found in the servlet API.
I've tossed around the idea of a JSR for mailets, but there are enough narrow JSRs already, and I don't think we could get as much mileage from the servlet spec as possible. In a round-about way, James HAS gotten a lot of mileage from the servlet spec because it was on the same site as Tomcat, the reference implementation. At this point I think following the same J2EE design patterns will allow us to get traction from that community even more. Like you said, it'll be a learning experience if nothing else.Politically and consumer-wise it could really be a plus.
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
