james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Burrell Donkin" <robertburrelldon...@gmail.com>
Date Fri, 04 Apr 2008 22:00:59 GMT
one of the design aims of the new, baroque IMAP is to be easily extensible

for Commands with existing implementations, the typical use case is
retaining the codec whilst replacing the processing. this can be done
by amending the chain to replace the standard processor with an

for Commands without existing implementations, this means adding an
decoder for the Command, a processor for the request message plus
encoders for any novel responses. in this case, the processor and any
encoders would be added to the appropriate chains. currently, a map is
maintained of decoders against command name but this area needs
revising for security. anyway, the decoder would be added (somehow).

the problem is CAPABILITY. this command returns a list of capabilities
that the server supports

ATM this is hard coded in a global. this means that extensions cannot
add their capabilities and announce themselves as is required. RFC3501
(but not RFC2060) requires a secure mode with STARTTLS, LOGINDISABLED
and AUTH=PLAIN capabilities. this secure mode is incompatible with
older RFC2060 clients which do not support STARTTLS. so the
capabilities they advertise should also be configurable.

this suggests the introduction of a context (ImapContext, say) into
the design. this will need to store read-only initial configuration
information (strings? beans?), maintain a modifiable list of
capabilities (probably strings) and a version string.

the IMAP chains are created after upon configuration so it should be
possible to inject a fully initialised ImapContext


- robert

To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message