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:[email protected]] Gesendet: Donnerstag, 12. März 2009 22:10 An: [email protected] 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
