> The idea would be to factor out James protocol stacks into a set of
> nice and tidy packages to allow third party to reuse them to
> implement their own custom server side messaging solution.
They already can. And do.
> For example, I have a little project which deal with messaging [1].
> it also provides some server functionalities (e.g. POP and SMTP).
> I would have loved to be able to reuse James protocol stacks for this.
All you need to do is use an Avalon container, and pick the part(s) you
need.
> Unfortunately, James protocol implementation is tightly coupled with
> its overall infrastructure.
The James implementation is coupled only to the Avalon interfaces. The
linkage between SMTP, POP3 and other "protocol stacks" is decoupled through
the repositories.
> And using James as a whole for my modest needs was not an option.
More to the point, it appears that you don't understand how the components
are assembled.
> Therefore I had to write my own protocol stack
> to handle the server side of messaging :(
OpenIM is another protocol stack that we're hoping to integrate with James
to provide even broader capabilities.
> Perhaps James could consider providing such a SDK also by simply
> factoring out its different protocol stacks into their own self-contain
> packages, in the same way as JavaMail provides a developer kit for the
> client side of the equation.
What we'd need to do is refactor the configuration to demonstrate how to do
it.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
