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 07:19:47 GMT
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




Mime
View raw message