Author: norman
Date: Wed Aug 18 06:41:17 2010
New Revision: 986578
URL: http://svn.apache.org/viewvc?rev=986578&view=rev
Log:
Append delimiter to Namespace if Namespace length is bigger then 0 (IMAP-200)
Modified:
james/imap/trunk/message/src/test/java/org/apache/james/imap/encode/NamespaceR
[
https://issues.apache.org/jira/browse/IMAP-200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Norman Maurer resolved IMAP-200.
Resolution: Fixed
fixed
> NameSpaceResponseEncoder need to append delimiter on response
> --
Author: norman
Date: Tue Aug 17 20:22:26 2010
New Revision: 986474
URL: http://svn.apache.org/viewvc?rev=986474&view=rev
Log:
Append delimiter to Namespace if Namespace length is bigger then 0 (IMAP-200)
Modified:
james/imap/trunk/message/src/main/java/org/apache/james/imap/encode/NamespaceR
NameSpaceResponseEncoder need to append delimiter on response
-
Key: IMAP-200
URL: https://issues.apache.org/jira/browse/IMAP-200
Project: JAMES Imap
Issue Type: Bug
Compo
So, kind-of "let the store create the uid (range) and use it as nextuid"
In current impl, each mail persistence reads in a locking transaction
the persisted "lastUid" (for jpa), consumes it (+1) and re-persists it.
Each incoming mail queues for this thanks to the locking transaction,
giving pe
Well,
I think its not the generation of the UIDNEXT which is a performance
problem. Its how it is used atm. We currently use it as uid for the
next message which will get append to the mailbox. It would be more
performant to use an auto_increment column in jpa for example. Other
backends have othe
Eric,
you are right about the UIDVALIDITY, the default shouldn't be a random
number, but the current timestamp which would guarantee that it won't
occur again.
I also thought about checking whether the next uid would wrap the uid
counter to the negative - which would mean we need to regenerate the
... and one more general point :Should the UID API oblige (or not?)
each store to use the UIDNEXT from the memory ?
(or "Should the caching UIDNEXT mecanism be an optional utility, meaning
that each store could re-implement it in a different way - cached,
persistent or not ?").
Tks,
Eric
On
Hi Norman,
I've read the http://www.rfc-editor.org/rfc/rfc3501.txt (section 2.3.1
Message Numbers) and http://www.rfc-editor.org/rfc/rfc2683.txt (section
3.4.3. UIDs and UIDVALIDITY)
A first point is RFC talks about backend server not being able to store
the UIDs. In this case, the UID are
[
https://issues.apache.org/jira/browse/IMAP-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Norman Maurer resolved IMAP-197.
Resolution: Fixed
> Upgrade to jackrabbit 2.1.1
> ---
>
> Key
Author: norman
Date: Tue Aug 17 07:25:30 2010
New Revision: 986217
URL: http://svn.apache.org/viewvc?rev=986217&view=rev
Log:
Allow the NAMESPACE to return the "real namespace" (IMAP-177)
Modified:
james/imap/trunk/seda/src/test/resources/org/apache/james/imap/scripts/Namespace.test
Modifie
11 matches
Mail list logo
