[Sugar-devel] Overlay chat architecture

[Benjamin M. Schwartz]

Andrés Ambrois wrote:
> On Saturday 15 August 2009 06:50:06 pm Benjamin M. Schwartz wrote:
>> I've been thinking about overlay chat, and I wonder
>>
>> 1.  Has there been any code written to that end?
> 
> http://git.sugarlabs.org/projects/sugar-toolkit/repos/sugar-toolkit-chat

Interesting.

>> 2.  Has anyone thought about the necessary architecture?
>>
>> Overlay chat requires a number of things working together: per-activity
>> daemons, spawned when sharing starts, with references to the telepathy
>> channels for each activity, as well as bidirectional access to the Friends
>> tray for GUI.  It's not clear to me, for example, what code in Sugar could
>> launch such a daemon.
> 
> See sugar/src/jarabe/frame/friendstray.py. My idea was to keep it simple and 
> consistent by making the BuddyModel (jarabe/model/buddy.py) hold one of these 
> objects (the owner would hold a ChatPitcher, the rest a ChatCatcher*) and 
> expose a signal/method for events.
> 
> This would mean both the icons used in the friendstray and in the neighborhood 
> view have access to this service through the BuddyModel.
> 
> Also, I don't think we need a process for each activity. 

I think you are right, that we don't need a process for each activity, and
I think your design might well work.  I should confess, then, that my real
goal here is not only Overlay Chat.  I have also been thinking about "Push
To Talk" (the voice equivalent of overlay chat) and "shared activity
titles" (so that if I change the name of the activity, all participants
see the change).

These three functions all seem very similar to me.  They are all
Sugar-provided collaboration services that would be associated with an
activity session.  There may be other such services that I have not yet
considered, such as the mythical Bulletin Board.

> Since we can only
> show chats from one activity at a time, and telepathy holds unacknowledged
> messages. We can just subscribe a class method to 'chat-received' in all
> channels for notifications.

I suspect the "holding unacknowledged messages" behavior is unique to text
channels, and won't work for the other applications.  For those cases, we
will at least need one daemon to process incoming data as it arrives.  (A
single daemon could handle the function for all activity sessions, and
might not need to run in its own process.)  Also, Overlay Chat is unique
because Telepathy (or maybe the presence service?) guarantees that there
will be a text channel for every shared session.  The same is not true of
the other channel types required for other functionality.

--Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
Url : http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090816/ea24f991/attachment.pgp