esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vassil Dichev <>
Subject Re: Deleting user from access pool
Date Sat, 10 Oct 2009 20:26:32 GMT
> Yes, I have some questions.
> I already have a patch to delete the user from pool by delete Privilege.


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!


View raw message