[ 
https://issues.apache.org/jira/browse/IMAP-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13573362#comment-13573362
 ] 

Andrzej Rusin edited comment on IMAP-370 at 2/7/13 10:13 AM:
-------------------------------------------------------------

We can always copy/paste the CopyProcessor :D (just joking)

Or we can fix AbstractChainedProcessor.isAcceptable to not rely on reflection 
for business logic, which by itself is not really a best practice.

Or we can avoid complication by refactoring out a common abstract ancestor for 
Copy and Move processors.
                
      was (Author: arusin):
    We can always copy/paste the CopyProcessor :D (just joking)

Or we can fix AbstractChainedProcessor.isAcceptable to not rely on reflection 
for business logic, which by itself is not really a best practice.

I will look into it when I have more time (which may not be that soon).
                  
> Consider supporting the upcoming MOVE extension
> -----------------------------------------------
>
>                 Key: IMAP-370
>                 URL: https://issues.apache.org/jira/browse/IMAP-370
>             Project: James Imap
>          Issue Type: Improvement
>          Components: Protocol
>            Reporter: Andrzej Rusin
>         Attachments: IMAP-370-2.patch, IMAP-370-capability-v1.patch, 
> IMAP-370-v1.patch
>
>
> As we see at 
> http://datatracker.ietf.org/doc/draft-ietf-imapmove-command/ballot/ IETF is 
> about to finally accept the IMAP MOVE extension.
> This extension enables great performance optimization possibilities for the 
> more advanced Mailstore backends, eg the ones that use a underlying 
> relational or non-relational database: 
> One of the most common usage scenarios in IMAP is moving messages across 
> folders, and with the MOVE extention it can be finally accomplished without a 
> COPY/DELETE cycle on certain Mailbox backends.
> Therefore, in my belief, it would be very nice to have that extension 
> implemented in James.
> Some of the bundled Mailstore implementations already are based on SQL/noSQL 
> datasources, and can directly benefit from it.
> Some of the independent Mailstore implementations (including mine) can 
> benefit from it too.
> Some of IMAP clients (including Thunderbird as of 3.something) already 
> support that extension or the X-MOVE or X-AOL-MOVE one.
> So James has a great opportunity to be the leader of standards adoption on 
> the server side.
> What do you think? Please comment.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to