Hi all,
First of all I took Robert suggestion to use a prefix for this less
important messages about the experimental api.
In a way really similar to Danny's "Mailet API sandbox" this is thought
as an experiment to create a strawman implementation to talk about later.
I write this for curious and people that want to collaborate, provide
suggestions/hints/ideas or simply lurk, but I would put emphasys on the
fact that is much less important than any discussion related to official
release branches (v2.3 / trunk) and proposal related to releases (2.3.1,
next-minor, next-major).
There are currently 3 major ongoing tasks happening on the
handlerapi-experiment.
1. Push-based/Asynchronous protocol handling
2. "Hook based" public api for extensions
3. Generic handlers/hooks/smtpsession clean-up
I don't have a clear roadmap about what step to do next, but I think
that it deserve some more experiments before I (or Norman) will feel
fine creating a proposal based on that code.
And here are some more details on the status of the above tasks:
Push-based/Asynchronous protocol handling
=========================================
https://issues.apache.org/jira/browse/JAMES-750
This is something we discussed often in past, there are comments in the
JIRA. I did 3 steps on JIRA then Norman decided to apply my code so I
completed it directly on svn.
The patch attached to JIRA does include Hacks to make the data handling
asynchronous and push based (introduce piped streams and a worked thread).
Later I rewrote the current functionality to be push based (outputstream
vs inputstream) and line based.
Currently it is fully implemented but this will need much more care and
review if we'll ever decide to bring this to trunk.
It is important to note that this new approach should let us to smoothly
move to MINA. This also increased a lot the power of the low-level
handler api.
"Hook based" public api for extensions
======================================
Using this as inspiration:
http://wiki.qpsmtpd.org/plugin_hooks
Norman added the concept of Hooks that are extension points built over
the already extensible CmdHandlers.
The main difference between CmdHandlers and Hooks should be that Hooks
shouldn't be too much SMTP specific (e.g: not the same control over SMTP
return codes, no way to add/remove commands or to alter protocol syntax
checks).
We currently have AuthHook, EhloHook, HeloHook, MailHook, MessageHook,
QuitHook, RcptHook. This is far from definitive and I bet they will
change again in the next days.
The idea is that Hooks should be as easy as possible to be implemented
and possibly reusable in a Mailet container.
Currently this is not true because they still depend on SMTPSession, but
I hope we'll find a good solution to this soon.
Hooks could be considered the high-level "public" api. CommandHandlers
instead are the low-level "developer" api. New ESMTP extensions we'll
need CommandHandlers to be supported, but most user-configurations
should be possible by working with Hooks.
I think Norman and I both postponed the issue to a later date and in the
mean time we concetrate on clean up and rewrite current code to use
Hooks: this way it will be much more clear what we can do and how to do
that.
Having reviewed 4 different handlerapis (2.3.0, current trunk, current
handerapi-v2 branch, this sandbox) I *currently* think this sandbox and
this solution is promising.
Generic handlers/hooks/smtpsession clean-up
===========================================
This is a boring call-hierarchy, refactoring, information collection
task that I started to increase my understanding of the codebase
accessing SMTPSession.
This changed a lot, but I don't consider this a key part of the
experiment, so no need to go in depth yet.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
