On Thu, Aug 7, 2008 at 12:06 PM, Bernd Fondermann <[EMAIL PROTECTED]> wrote:
<snip> > Moving protocol related stuff into server-independent components will > soon raise technical questions: > > 1. What _is_ the 'protocol' domain? > 2. How does this domain interface with the rest of the system it is deployed > in? > > 'Protocol' for me connotes closely with 'connection', 'paser', > 'command' and 'command handling', and not so closely with 'session', > 'session state' and 'interfacing backend services'. At some point we'd > have to draw a line and define what's inside the protocol domain and > how this interfaces with the rest. IMHO each protocol needs to define it's own boundaries. IMAP is a session based stateful protocol with very peculiar backend requirements. JAMES server would then weave each protocol into a cohesive system > I tried to do this in a layered way (onion) in Vysper, not sure how > much the architectural patterns from there can be applied to James. > Another interesting aspect for me is that POP3 is somehow a functional > subset of IMAP. How do we do this right without duplication? POP3 and IMAP are similar conceptually but each specification approaches the problem quite differently. sharing behaviours (interfaces) is inappropriate in this situation. POP3 only requires a very shallow knowledge of the mail. IMAP requires that a mail is completely decomposable into it's constituate parts. POP3 can be used with a wide varieties of backends. IMAP requires a specialised backend with associated overhead. i think that the level of commality is much lower, at the data store level. i'm very interested in mime-based meta-data aware mail stores (note mail, not email). for example, i think that it'd cool to be able to have JAMES Fetch an RSS feed, filter using SIEVE and then expose through IMAP, POP3 or NNTP. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
