incubator-esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Pollak <>
Subject Re: ESME Groups
Date Fri, 13 Mar 2009 09:07:17 GMT
I have in the past and will continue to bristle over calling pools groups.
 They are not.

Facebook's new front page has groups.  Groups are personal things where I
assign different people into different groups and the meaning of a group is
individual to me and it's all about my view of the world.  This keeps to the
"opt in" mechanism that we absolutely must preserve in ESME.  If we do this
type of group in the future, that's way cool, but once again, it's a
personal thing that has nothing to do with access control or "sending".

Darren and I talked about pools.  Pools are collections of messages that can
only be read by people who have been granted access to that pool.
 @pool_name *DOES NOT* "send to that pool."  A person who has access to a
pool is see messages put into that pool that otherwise meet the person's
criteria (who they are following, what their filter rules are.)  There is no
"send to a pool" concept.  It's "place a message in a pool" and all messages
are placed in one and only one pool and by default, that pool is the
server-local public pool.  We can automagically create pools based on LDAP
groups.  We can automagically add/remove access to pools based on LDAP
groups.  We can mirror what LDAP does without destroying the most important
piece... ESME is opt-in.

A User has a relationship with a pool.  That relationship is
read/read-write/administer (which implies read-write).  If someone
@pool_name a message, that message will be posted to whatever pool it would
otherwise be put in as well as put in the mailbox of all administrators of
the named pool as long as those people had access to the pool that message
was also put in.  This allows a user to request access to a give pool
without having to know the names of the administators of the pool.

So, how do you get a message into a pool?  You will define your default
pool.  This is the pool that your messages get put into unless you specify
otherwise.  This means that the CEO can choose to put things in the
"c-level" pool by default.  Most people will post to the public pool by
default.  If you are in a text-only interface, you will do the following:
d pool_name message

This is a direct message to the pool.  This is just like the upcoming direct
message to a person.  Darren came up with the idea and the semantics are

We may choose to layer a UI on top of this with a pull-down for target pool
and maybe even change the UI (color or image or icon) to reflect the target

I understand that we are using groups and pools to mean something different
than people are used to.  ESME is a different medium than people are used
to.  That gives EMSE its power.  ESME is powerful because it is a dynamic,
opt-in, social medium rather than a point-to-point communications medium.
 There are different concepts in ESME than in point-to-point mediums.  Let's
do the extra work now to make sure we understand those differences and
celebrate those differences and get others excited about those differences
so that ESME can thrive for what it is... a social tool for social animals.



On Fri, Mar 13, 2009 at 7:19 AM, Hirsch, Richard <
> wrote:

> Good to hear that Darren and David have started thinking about groups.
> I think it is important to focus on the pool functionality described by
> Bill in his email from Feb 19.  One Jira item for the whole functionality
> isn't granular enough to work, so we need to break it down into bite-size
> chunks and create JIRA items based on that. As Vassil stated in a tweet, the
> problem is that this functionality is spread across so many Scala classes
> that it might be difficult to create smaller chunks / JIRA items.
> In initial versions, I'd like to concentrate on the Scala core rather than
> the UI.  What about adding functions to the existing RESTAPI to test the new
> group-related functionality?
> I'd like to try and define a few potential JIRA items via the mailing list
> before moving it to JIRA. Inasmuch as I don't have the technical background
> in Scala or lift, this may be difficult but I still like to give it a try.
> The following is an initial list. I know David had other ideas about
> privacy, pools and I don't know whether my first ideas match his ideas. In
> order for this breakdown into smaller chunks, there must be someone who
> describes the basic technical Scala / lift architecture so that those who
> are working on JIRA items have a basic idea of how there piece fits into the
> greater scheme of things.
> I've checked the existing code base and there a quick few locations where
> the use of groups is already present (Distributor, etc.) I've seen that
> Message object already has the "viaGroup" attribute. Can we re-use this
> attribute?
> I'd like to separate the basic group administration functionality from the
> group-related functionality in messages (with the new SecurityManager).
>  That way we may be able to create various work packages simultaneously.
> Vassil would be able to work on Package 1 and Darren and David could work on
> Package 2.
> Anne informed me last night that Pearl is having its annual customer
> meeting on April 23 - 24 and Anne may be able to present ESME at this
> meeting. What about attempting to get a groups prototype with Phase 1 and 2
> up and running until then?
> Package 1:
> - Initially all groups will have "public" visibility
> * There are already Group and GroupActor objects - Don't know whether we
> should re-use these objects or not.
> * Ability to create group with name, description, visibility, list of
> administrator (Creator is first administrator)
> * Ability to add a user to a group
> * Ability to delete a user to group
> * Ability to delete a group
> * Ability to get list of groups
> * Ability to get a list of groups in which I am a member
> * Ability to get of users for a group
> Package 2:
> * Security Manager
> * Ability to send a message to a group . Should we have a syntax
> "to:groupname"
> * Ability to view all messages in a group
> * Change existing public timeline to public group (as described by Bill)
> Package 3:
> * Ability to make a group private
> * Ability to make a group public
> * Invite a user to group
> * Add administrator to a group
> * Delete an administrator from a group
> Package 4
> * Search for messages in a group
> How does that sound?
> D.
> -----Ursprüngliche Nachricht-----
> Von: Darren Hague []
> Gesendet: Donnerstag, 12. März 2009 22:10
> An:
> Betreff: ESME Groups
> The results of David and my pub-based design session are now in the
> Apache ESME wiki:
> Yes, this is just a photo of a notebook page right now. I will decrypt
> this and update the wiki, but we were basically riffing on how to
> implement the group/pool ideas we all thrashed out here on the list a
> few weeks ago, in combination with a security model which will not
> cripple system performance (not a trivial idea).
> Step 1, I think, will be to implement a Security Manager concept which
> can be applied to the reading/writing of messages. Following on from
> this, we can build the internals of the Security Manager implementation
> - this will utilise the group concept. In parallel, it would be good if
> the UI guys can start thinking about how users would create/edit
> groups.  As an initial idea for actually sending the messages, simple
> Twitter-like d- and @-syntax can be used to refer to groups as well as
> users.
> Thoughts, anyone?
> Cheers,
> Darren

Lift, the simply functional web framework
Beginning Scala
Follow me:
Git some:

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