[jira] Created: (JAMES-725) Redesign the Imap Command API to follow more SoC

["Joachim Draeger (JIRA)" <se...@james.apache.org>]

Redesign the Imap Command API to follow more SoC
------------------------------------------------

                 Key: JAMES-725
                 URL: http://issues.apache.org/jira/browse/JAMES-725
             Project: James
          Issue Type: Improvement
          Components: IMAPServer
    Affects Versions: Trunk
            Reporter: Joachim Draeger
         Assigned To: Joachim Draeger


The current design is really not bad and for the most commands absolutely sufficient. 

But at least search and fetch are candidates to follow a more strict template.

1. parse the complete command and put the information into a request object
2. apply the request: perform changes / fetch data, return a response object
3. render the response

Parts of the request/response objects could come from the backend API (MailboxManager)

This should be done in three 3 classes that can be tested separately. For trivial commands we could allow simplification like nested classes.
(This is only a very quick draft of things I have in mind)
Another resource is handlerapi2, of course.

It should integrate smoothly in the current code base, without the need to change all commands at once. (At first only Fetch and Search)
Running from AbstractJamesHandler is mandatory. 
(one step after the other, keep backward compatibility)

Ideally we could use existing solutions and follow the schema of MINA. 
We could prepare a future switch to MINA and make first experiments.

Maybe we could make use of ANTLR for the parsing part.



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

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

[jira] Closed: (IMAP-11) Redesign the Imap Command API to follow more SoC

["Robert Burrell Donkin (JIRA)" <se...@james.apache.org>]

     [ https://issues.apache.org/jira/browse/IMAP-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Robert Burrell Donkin closed IMAP-11.
-------------------------------------

       Resolution: Fixed
    Fix Version/s: 0.1
         Assignee: Robert Burrell Donkin  (was: Joachim Draeger)

Split into codec and processors which communicate via messages only.

> Redesign the Imap Command API to follow more SoC
> ------------------------------------------------
>
>                 Key: IMAP-11
>                 URL: https://issues.apache.org/jira/browse/IMAP-11
>             Project: JAMES Imap
>          Issue Type: Improvement
>            Reporter: Joachim Draeger
>            Assignee: Robert Burrell Donkin
>             Fix For: 0.1
>
>
> The current design is really not bad and for the most commands absolutely sufficient. 
> But at least search and fetch are candidates to follow a more strict template.
> 1. parse the complete command and put the information into a request object
> 2. apply the request: perform changes / fetch data, return a response object
> 3. render the response
> Parts of the request/response objects could come from the backend API (MailboxManager)
> This should be done in three 3 classes that can be tested separately. For trivial commands we could allow simplification like nested classes.
> (This is only a very quick draft of things I have in mind)
> Another resource is handlerapi2, of course.
> It should integrate smoothly in the current code base, without the need to change all commands at once. (At first only Fetch and Search)
> Running from AbstractJamesHandler is mandatory. 
> (one step after the other, keep backward compatibility)
> Ideally we could use existing solutions and follow the schema of MINA. 
> We could prepare a future switch to MINA and make first experiments.
> Maybe we could make use of ANTLR for the parsing part.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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