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-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
