[
https://issues.apache.org/jira/browse/JAMES-3074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
René Cordier updated JAMES-3074:
--------------------------------
Description:
By doing an attempt on strong typing UidValidity, it raised a lot of questions
and issues on how it is managed actually in James (see
[https://github.com/linagora/james-project/pull/3132]). The result is we likely
have many invalid UID_VALIDITY generated in James.
The proposition to enhance UidValidity usage in James is the following one (in
2 phases):
* tactical move: merge the strong typing + ensure we don't generate new
invalid values. This will at list help with new deployments:
** strong type UidValidity
** use UidValidity.of only for deserialization, to not break already existing
running James instances
** use a factory with a create method that should be the only way used for
generating new UidValidity. It needs to be unique, respecting the RFC
definition, using **random**:
{code:java}
nz-number = digit-nz *DIGIT
; Non-zero unsigned 32-bit integer
; (0 < n < 4,294,967,296)
{code}
* strategical move: fix all and every invalid UID_VALIDITY (at the cost of
resynchronisation)
IMAP RFC: [https://tools.ietf.org/html/rfc3501#section-2.3.1.1]
was:
By doing an attempt on strong typing UidValidity, it raised a lot of questions
and issues on how it is managed actually in James (see
[https://github.com/linagora/james-project/pull/3132]). The result is we likely
have many invalid UID_VALIDITY generated in James.
The proposition to enhance UidValidity usage in James is the following one (in
2 phases):
* tactical move: merge the strong typing + ensure we don't generate new
invalid values. This will at list help with new deployments:
** strong type UidValidity
** use UidValidity.of only for deserialization, to not break already existing
running James instances
** use a factory with a create method that should be the only way used for
generating new UidValidity. It needs to be unique, respecting the RFC
definition:
{code:java}
nz-number = digit-nz *DIGIT
; Non-zero unsigned 32-bit integer
; (0 < n < 4,294,967,296)
{code}
* strategical move: fix all and every invalid UID_VALIDITY (at the cost of
resynchronisation)
IMAP RFC: [https://tools.ietf.org/html/rfc3501#section-2.3.1.1]
> [Refactoring] UidValidity strong typing
> ---------------------------------------
>
> Key: JAMES-3074
> URL: https://issues.apache.org/jira/browse/JAMES-3074
> Project: James Server
> Issue Type: Improvement
> Reporter: René Cordier
> Priority: Major
> Labels: bug
>
> By doing an attempt on strong typing UidValidity, it raised a lot of
> questions and issues on how it is managed actually in James (see
> [https://github.com/linagora/james-project/pull/3132]). The result is we
> likely have many invalid UID_VALIDITY generated in James.
> The proposition to enhance UidValidity usage in James is the following one
> (in 2 phases):
> * tactical move: merge the strong typing + ensure we don't generate new
> invalid values. This will at list help with new deployments:
> ** strong type UidValidity
> ** use UidValidity.of only for deserialization, to not break already
> existing running James instances
> ** use a factory with a create method that should be the only way used for
> generating new UidValidity. It needs to be unique, respecting the RFC
> definition, using **random**:
> {code:java}
> nz-number = digit-nz *DIGIT
> ; Non-zero unsigned 32-bit integer
> ; (0 < n < 4,294,967,296)
> {code}
> * strategical move: fix all and every invalid UID_VALIDITY (at the cost of
> resynchronisation)
> IMAP RFC: [https://tools.ietf.org/html/rfc3501#section-2.3.1.1]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
