james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Charles (JIRA)" <server-...@james.apache.org>
Subject [jira] Commented: (IMAP-221) nz-numbers must be unsigned 32bit ints
Date Tue, 05 Oct 2010 09:01:33 GMT

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

Eric Charles commented on IMAP-221:
-----------------------------------

Hi,

>From RFC, I don't think the importance is to have long, int, biginteger or whatever types
in the implementation.
The important point is that the returned string represents a number n such as 0 < n <
4,294,967,296.

So rather than trying to choose a primitive type or existing class such as Integer,... building
our own value object is probably the most flexible way, and I really like the expressive nature
 of a separate class to represent/map the RFC.

If we want to go on with this logic, we should also change all methods signature in imap/store
projects and replace all Long with NzNumber ?

Example: 
  Long MessageMapper<Id>.findFirstUnseenMessageUid(Mailbox<Id> mailbox)
would become
  NzNumber  MessageMapper<Id>.findFirstUnseenMessageUid(Mailbox<Id> mailbox)

If we do this, we certainly have much to change...
An alternative approach would be to restrict the NzNumber inside some methods (the important
ones who create/validate them), but I find this a half solution.

btw, we could also think to introduce JSR303 to validate NzNumber (with spring provided jsr303,
or still better with upcoming http://wiki.apache.org/incubator/ValidationProposal)
This is a really simple use case, but could be a case for jsr303 within james.


> nz-numbers must be unsigned 32bit ints
> --------------------------------------
>
>                 Key: IMAP-221
>                 URL: https://issues.apache.org/jira/browse/IMAP-221
>             Project: JAMES Imap
>          Issue Type: Bug
>          Components: Parser, Protocol
>    Affects Versions: 0.1
>            Reporter: Norman Maurer
>            Assignee: Norman Maurer
>             Fix For: 0.2
>
>
> Currently we use long/Long as return type when a message uid is retrieved. Thats wrong
as the RFC only allow 32-Bit numbers. We should change the methods to make this clear.

-- 
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


Mime
View raw message