esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Xuefeng Wu <>
Subject Re: Deleting user from access pool
Date Sun, 11 Oct 2009 00:11:48 GMT
@Vassil, thank you for  your reply. Great analysis!

On Sun, Oct 11, 2009 at 4:26 AM, Vassil Dichev <> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message