Hi,
I'm finally also +1 for UUID.
There's always a price to pay for any option, but the challenges we will
have to solve in the message (especially for search) will be a few level
higher.
So for now, I would simply to worry on scanning the whole mailbox table.
There will be also the possibility to add secondary indexes (just put it
aside for now, indexes with HBase is not ready for primet ime).
So there is room for improvement, just go on with UUID.
Thx.
On 11/07/11 20:05, Norman Maurer wrote:
Hi Ioan,
I think it would be the best to use an UUID as key. This way you would
not need to "update" every message metadata if someone renamed the
mailbox. You will need to make 2 queries in this case but I think its
worth it.
Bye,
Norman
2011/7/11 Ioan Eugen Stan<[email protected]>:
Hello,
Development on the mailbox is going well, I am nearly done with
implementing MailboxManager. After this, the route will be
SubscriptionManager and MessageManager.
We are facing some issues regarding the key choice that will determine
the way to access mailboxes.
The MAILBOXES HBase table stores information about individual
mailboxes. The current values stored are: Name, Namespace, User (who
is probably owner of the mailbox ???), uid validity field, last uid,
highest mod seq, for which I don't know the purpose, and mailbox ID.
After discussing with Eric, I have switched from using the mailbox ID
as a row key to using one like „user:namespace:name”.
Eric pointed out that mailboxes can be renamed and we should switch
back using the UID as a rowkey. We agreed that it's best to have an
open discussion about this.
The mailbox search API provides access only to a MailboxPath, that we
have to use in order to find information about the mailbox. If we use
a rowkey like "user:namespace:name", finding the mailbox and getting
the information is a simple Get operation. Also, finding mailboxes
that contain that mailbox name is a scan with a partial key, so again
pretty fast.
If we are using the mailbox ID as a row key, finding a mailbox by it's
path is more difficult. We have to either scan the entire table, or
store additional information in the users account (like what mailboxes
does he have, and what are their ID's, and get them by ID).
My thoughts:
The IMAP RFC states that a user can not send commands that affect
messages unless he is in „Selected State”, that is he has
successfully selected a mailbox (SELECT or EXAMINE). To get into
selected state he must be first authenticated. The user must also have
a primary mailbox called „INBOX”. I think we can use this to form a
key, and store some valuable information that we can use for other
cases.
What do you think?
Regards,
--
Ioan Eugen Stan
http://ieugen.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
