incubator-esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vassil Dichev <vdic...@apache.org>
Subject Re: The Pool stuff is good to go
Date Sat, 20 Jun 2009 10:47:58 GMT
> @Vassil: Can you provide a very quick description of the pool functionality
> that you implemented.

Of course, here's what you can do with pools.

On the "Manage Access Pools" page:
* You can create a new pool. By default you are an administrator of
this pool. There is a column which indicates the realm of the access
pool, indicating how the pool was created. Currently it's just a
string and if the Web UI is used it is "Native".
* You can set permissions for a user in a pool (if you have Admin
permissions yourself)- Read, Write or Admin.

On the message page:
* Users who have Write permissions can send a message to this pool via
a menu. By default you can send the message without any pool assigned
to it, i.e. to the so called public pool.
* Users can see in their timeline messages in the public pool and in
pools for which they have permissions. There's currently no page where
you can see messages only from a specific pool, nor does the Web UI
show which pool a message belongs to.
* Messages which belong to any pool don't appear in the public timeline.
* Messages in a pool for which a user doesn't have permissions cannot
be tracked and shouldn't show on the Tracking page.

There's also RESTful API for creating a pool, setting permissions of a
user in a pool and sending a message to a pool (described in a
previous mail).

What *doesn't* work yet:
* Messages are still shown where they shouldn't be visible. For
instance, when you view another user's timeline, you can see all of
their messages regardless of the fact you shouldn't have access to
them. Seeing all messages from the Twitter API shouldn't be allowed
either and is actually a bug! Remember- pools are not meant for just
filtering content based on topic or interests, but for access control.
In this way they are a bit different from Yammer's groups because we
don't have public groups. It's probably more similar to Yammer's
private groups.
* You cannot delete a pool. In ESME different entities, like tracking,
actions, are not deleted from the database, but marked as disabled.
Probably same policy would apply to pools.
* You cannot currently remove a user from a pool, which is one of the
first thing I want to implement next.
* You cannot rename a pool.
* You cannot search/track by pool or use them in actions (and I'd like
ESME to be able to use them).

I have a small outline of what pools can do. When I combine it with
the explanations in several mails I plan to publish a more complete
document on the wiki.

Have fun,
Vassil

Mime
View raw message