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 alternative.
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 questions? opinions? - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
