#4043 HIGH Update.: [discussion] Group support in gabble and salut

[Zarro Boogs per Child]

#4043: [discussion] Group support in gabble and salut
------------------------------+---------------------------------------------
  Reporter:  kimquirk         |       Owner:  smcv    
      Type:  enhancement      |      Status:  new     
  Priority:  high             |   Milestone:  Update.2
 Component:  telepathy-other  |     Version:          
Resolution:                   |    Keywords:          
  Verified:  0                |  
------------------------------+---------------------------------------------

Comment(by smcv):

 Some thoughts on implementation:

 Given what Eben has said, Telepathy's HANDLE_TYPE_GROUP isn't a suitable
 representation for OLPC groups, so we won't be using that. (It models XMPP
 roster groups, which are private tags placed on a user's buddies by the
 user - completely different.)

 Representing OLPC-groups by XMPP server MUC chatroom affiliations seems a
 sane mapping; this would automatically give us (A) a chatroom per OLPC-
 group and (B) convenient server-side storage.

 This would mean that each MUC is either an activity, or an OLPC-group, or
 a non-OLPC chatroom (we don't really support the latter very well on OLPC,
 but they exist and we have to think about them, if only to say
 "unsupported").

 The requirement to support colliding OLPC-group names means we have to use
 a pseudo-random string, or a UUID, or something (generated by the creator
 of the group) for its JID, rather than creating a meaningful JID, much
 like we do with activity IDs - the real name of "Class 3a" will have to be
 something like 45729a98f472cc39de at groups.cambridge.xs.laptop.org rather
 than Class.3a at groups.cambridge.xs.laptop.org.

 We could either give groups a prefix on their random JIDs to stop them
 colliding with activities, or use two MUC services (e.g. groups.foo and
 activities.foo) to host their chatrooms.

 The requirement for OLPC groups to have no privileged users requires that
 we automatically promote every member to be an owner. (XMPP MUCs have a
 concept of access levels and roles, whether we want it or not - the owner
 can designate others as owners, so the easiest thing would be to just
 promote everyone we invite to have owner status. We plan to do the same
 thing at some point for activities to guarantee everyone has full control,
 which I'll file a bug about).

 The bboard file-sharing could be implemented with Tubes or file transfers
 in the OLPC-group's MUC, and/or with some sort of online file storage.

 The desired membership of the OLPC-group will have to be cached in the XO
 (probably in the PS) for offline use, with changes pushed to the server
 when we go online.

 At the Telepathy level, we probably want OLPC-groups and activities to
 look very similar - it's only in the Presence Service API that they need
 to start looking different.

-- 
Ticket URL: <http://dev.laptop.org/ticket/4043#comment:9>
One Laptop Per Child <http://dev.laptop.org>
OLPC bug tracking system