Mailing-List: contact esme-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: esme-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: AW: ESME Groups
Date: Fri, 13 Mar 2009 08:19:47 +0100
Message-ID: 
 <30DB6ACF50A0A3439F39EFEB1C52E16607CB988E@nets13ja.ww300.siemens.net>
In-Reply-To: <49B97A45.8020504@fortybeans.com>
Thread-Topic: ESME Groups
Thread-Index: AcmjVyI+r0Gv2Wb9SB6HjVcVTvEBkwAUrCdw
References: 
 <30DB6ACF50A0A3439F39EFEB1C52E166078F233F@nets13ja.ww300.siemens.net>
 <cdbebedf0903011331i3eb9d8d0na3bf48028aec6677@mail.gmail.com>
 <65C94484-A8D1-4AD5-B2A9-B6356E22755C@gmail.com>
 <49B97A45.8020504@fortybeans.com>
From: "Hirsch, Richard" <richard.hirsch@siemens.com>
To: <esme-dev@incubator.apache.org>

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.=20

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.=20

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.=20

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?=20

Package 1:=20

- 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.=20

* Ability to create group with name, description, visibility, list of =
administrator (Creator is first administrator)
* Ability to add a user to a group=20
* Ability to delete a user to group=20
* Ability to delete a group=20
* 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=20

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=20
* Change existing public timeline to public group (as described by Bill)

Package 3:=20
* Ability to make a group private
* Ability to make a group public
* Invite a user to group=20
* Add administrator to a group
* Delete an administrator from a group

Package 4
* Search for messages in a group


How does that sound?=20

D.=20

-----Urspr=FCngliche Nachricht-----
Von: Darren Hague [mailto:dhague@fortybeans.com]=20
Gesendet: Donnerstag, 12. M=E4rz 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=20
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=20
this and update the wiki, but we were basically riffing on how to=20
implement the group/pool ideas we all thrashed out here on the list a=20
few weeks ago, in combination with a security model which will not=20
cripple system performance (not a trivial idea).

Step 1, I think, will be to implement a Security Manager concept which=20
can be applied to the reading/writing of messages. Following on from=20
this, we can build the internals of the Security Manager implementation=20
- this will utilise the group concept. In parallel, it would be good if=20
the UI guys can start thinking about how users would create/edit=20
groups.  As an initial idea for actually sending the messages, simple=20
Twitter-like d- and @-syntax can be used to refer to groups as well as=20
users.

Thoughts, anyone?

Cheers,
Darren