@Vassil, thank you for your reply. Great analysis! On Sun, Oct 11, 2009 at 4:26 AM, Vassil Dichev <[email protected]> wrote:
> > Yes, I have some questions. > > I already have a patch to delete the user from pool by delete Privilege. > > Xuefeng, > > Thanks for all your work! I'm sorry for the delayed reply, I wasn't > online for some time. > > > I have some questions when run your user case at . > > 1. After delete user from pool, he/she could not see the pool's messages > > which already in mailbox. > > And the some he/she can not find any message from the pool from *Streams* > > Yes, you're correct that this behavior is not very consistent. > Currently what you see in the mailbox will sometimes show messages not > seen via other means (streams, going to a user's personal timeline, > search, etc.), and vice versa. Whether a message goes in the Mailbox > is decided on what pools a user is at the time the message has been > received, and then the message is there forever. What's in streams is > filtered by what pools a user is currently in. There is a single place > where I control which messages a user can see, so we can change that > if there's the wish to do so. > > For our purposes, let's discuss only the Mailbox (mail-box? should we > rename this class?) That's what the user will see on his timeline. > > > 2. If user B follow user A and delete user B from a pool, and A write > > message in the pool. > > B will receive* the messages *from A which is writen in the pool. > > > > I think that the cache is UserActor: > > private var pools: Set[Long] = Set() > > > > I need to add many method to refresh it for every following, is there any > > easy way? > > > > I attach the patch although it did not work perfect. > > I see that you're already getting deep in the access pools > implementation. Yes, the pools variable is the in-memory pool set of > the corresponding user. This is why anytime I add a pool, I send a > message (AllowUserInPool) to Distributor, and it sends a message to > UserActor in turn (AllowPool) to refresh this variable. We need to add > handling for DisallowPool or something similar- it should be very > similar to what's done for AllowPool. > > As for method followingIdsForUserId, there is already a variable in > UserActor, called followers (similar to pools above), doesn't it fit > the purpose? Note that it's better to send messages to the actors than > use methods, because messages are synchronized on an internal message > queue. I can tell you more when I see some code. > > Regarding history of permissions: very good idea. This is also one > more reason to use a discrete permission type- NoPermission, instead > of another field- isValid. This way we can just create a new > permission type in the DB with a timestamp and it would be much easier > to track what has changed and when. So if a user had read permission, > then write permission and then is deleted, the history would show > Read, Write and NoPermission in a chronological sequence. Does this > make sense? > > Thanks again for the progress, please keep it up and don't hesitate to > tell us where the pain points are! > > Vassil > -- Global R&D Center,Shanghai China,Carestream Health, Inc. Tel:(86-21)3852 6101
