incubator-esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hirsch, Richard" <richard.hir...@siemens.com>
Subject AW: ESME Groups
Date Fri, 13 Mar 2009 10:15:19 GMT
I'll give the blog entry a shot.  I'll write a first draft, post to the mailing list, get comments
and then post it on the ESME blog. 

I still think we will need an initial pool administration functionality dealing with creation
/ deletion of pools, etc. Of course, if everything originates from an LDAP, there is less
administration effort necessary but I think we should assume that in some environments that
the use of LDAP won't be possible. 

Is there anything from Lift that we can use from the Pool functionality?  

I actually like the message focus rather than user focus - it sets us apart and, as David
suggests, matches well with ESME's opt-in character. 

D. 


-----Ursprüngliche Nachricht-----
Von: Darren Hague [mailto:dhague@fortybeans.com] 
Gesendet: Freitag, 13. März 2009 11:03
An: esme-dev@incubator.apache.org
Betreff: Re: ESME Groups

David,

Thanks for laying this out. It now finally dawns on me why it's important to use the term
"pool" rather than "group": a pool is about the messages, a group is about the people. Of
course, via LDAP etc, we can implement pool security by mapping to LDAP groups, and (as you
say) even create pools based on groups. Using the term "group" might lead people to think
they are sending a message to a group of people, whereas they will actually be making it *available*
to a group of people, should anyone in that group choose to look in the pool.

Now that's sorted out, while we go ahead and do some implementation of the idea, how about
someone who's more gifted with language and diagramming skills writes this up into a blog
entry?  User education will be a key factor for this one...

Cheers,
Darren

>Folks,
>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
>perfect.
>
>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
>pool.
>
>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.
>
>Thanks,
>
>David
>
>
>On Fri, Mar 13, 2009 at 7:19 AM, Hirsch, Richard <richard.hirsch@siemens.com
>> 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 [mailto:dhague@fortybeans.com]
>> Gesendet: Donnerstag, 12. März 2009 22:10
>> An: esme-dev@incubator.apache.org
>> Betreff: ESME Groups
>>
>> The results of David and my pub-based design session are now in the
>> Apache ESME wiki:
>> http://cwiki.apache.org/confluence/display/ESME/ESME+Groups
>>
>> 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 http://liftweb.net
>Beginning Scala http://www.apress.com/book/view/1430219890
>Follow me: http://twitter.com/dpp
>Git some: http://github.com/dpp



-- 
darren.hague@fortybeans.com

Mime
View raw message