[
https://issues.apache.org/jira/browse/IMAP-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13526297#comment-13526297
]
Eric Charles commented on IMAP-370:
-----------------------------------
I looked at your first shot, and it looks good aside the points you mention.
Yes, we the ideal would be to lock the source folder, but as we don't either
lock for COPY, it could be committed as such.
I would be good to have the implementation for at least maildir, and jpa.
I don't think the legacy MOVE should be supported, but if you do it, why not
Thx, Eric
> 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-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]
