james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Tellier <be...@minet.net>
Subject Re: server/protocols vs protocols (was Re: My thoughts on JMAP implementation)
Date Mon, 14 Dec 2015 09:51:05 GMT

Le 14/12/2015 08:19, Matthieu Baechler a écrit :
> 
> 
> On 13/12/2015 12:43, Tellier Benoit wrote:
> 
> [...]
> 
>>   - First point, I believe /server/protocols is only here to wrap up the
>> /protocols stuff. We of course should have the servlets in
>> server/protocols. The responsibilities of such server/protocols are for
>> me to identify commands and encode responses + directly talk to the
>> client. /protocols is responsible of interacting with other James
>> entities (such as repositories and mailbox project) in order to reply to
>> the user commands. Such an organization allows not to be tied to jetty.
>> What do you think of it?
> 
> I'm ok with this idea, we took some shortcut while implementing this
> feature but we can now make it fit the usual James split of components.
> 
> Note that Jetty is already abstracted away. Servlet are not, but it
> might be difficult to abstract when we'll need to interact with headers
> in response. We'll see how to handle this.

The need to hook on the transport layer is a common need seing the
differents protocols implementations :

 - IMAP StartTls
 - I did the same for ManageSieve
 - IMAP IDLE
 - ... ( there might be others )

> 
>> This, I guess mean moving the RequestHandler, and most of the models in
>> /protocols. I don't believe it would be harder than that, and allow
>> protocols/jmap to become the first lib for JMAP in JAVA (kind of
>> advertisement for James ? Maybe it can be helpful...)
> 
> Not a lot of value right now but if people want to use it out of James
> context, why not ?
> 

+1 , I just wanted it to be discussed here. And to add to your point
servlets are defined in javax.

Maybe moving server/protocols/jmap to protocols/jmap when you are done
with the implementation would be enough.

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


Mime
View raw message