@Xuefeng: which question is still open? What should be the subject of the new Jira item?
D On Mon, Oct 12, 2009 at 11:42 AM, Xuefeng Wu <[email protected]> wrote: > @Vassil, Would do you resolve there question or Richard will create new jira > item? > > > 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 >
