[standards-jig] RE: LAST CALL: MUC (JEP-0045)

M.Eisenstadt at open.ac.uk M.Eisenstadt at open.ac.uk
Tue Nov 5 23:19:22 UTC 2002


Thanks, Peter... good points; I guess my problem with vote-bots and
countdown-bots is that I'm not sure they address the fundamental problem of
fine-grained event synchronisation within rooms, particularly for parallel
events, which is why I raised it here.  On the other hand, I agree that
add-on bot features over and above the core MUC protocol may be best for
sanity.  As long as we have the hooks to do synchronisation, then I'm happy.
Cheers
-Marc
  Marc Eisenstadt
  Knowledge Media Institute, The Open University, UK
  HOME OF OPEN SOURCE BUDDYSPACE = http://buddyspace.sourceforge.net

> Date: Mon, 4 Nov 2002 15:00:15 -0600 (CST)
> From: Peter Saint-Andre <stpeter at jabber.org>
> To: "'standards-jig at jabber.org'" <standards-jig at jabber.org>
> Subject: Re: [standards-jig] RE: LAST CALL: MUC (JEP-0045)
> Reply-To: standards-jig at jabber.org

> Hi Marc,

> Those are interesting use cases but I think they're somewhat specialized.
> They could probably be done in an extended namespace implemented via an
> in-room bot or a modified conferencing component. I would love to see
> people offer add-on features like this but I'm not sure they belong in the
> core MUC protocol. I know that Ryan and I have talked about building a bot
> that would handle voting in a room, though we didn't around to it for the
> most recent JSF election cycle. I would recommend using jabber:x:data for
> that -- send the "ballot" to all the participants and they can fill it out
> and send it back to the bot or the room.

> Or so it seems to me. :)

> Peter

> --
> Peter Saint-Andre
> Jabber Software Foundation
> http://www.jabber.org/people/stpeter.php

> On Sat, 2 Nov 2002, M.Eisenstadt wrote:

> I have two MUC user/moderator cases that I'd like to raise as 'food for
> thought': they arise surprisingly often in my educational context (e.g.,
> virtual classrooms), and although they can be handled with existing
presence
> or even plain text message/bot tricks, there may be more elegant solutions
> lurking out there, hence this email...
> 
> In a nutshell, the two specific cases are (i) synchronized
countdown-timers
> and (ii) (nearly)simultaneous voting in a multi-user chat. The more
generic
> issues concern, in case (i), timing, syncopating, or what I prefer to
think
> of as 'metronoming' of group behaviours, e.g. 'Quiz 29 (or breakout
session
> 3, or Battleship Game 9, etc.) will begin in 3:00 minutes, starting....
> NOW'.  In case (ii), although of course users can vote by typing 'Y' or
> toggle their presence states to indicate (say) 'agreement', the generic
> issue has to do with conveyance of an expressive state that does not
> strictly belong to the domains of either 'presence' or 'text', and may
> therefore warrant some kind of 'channel' of its own to open up other
> comparable possibilities-- especially true if one wants a degree of
> parallelism in the 'votes', let alone the ability of (only) a moderator to
> 'clear' prior 'votes'.  Voting is only one example: future possibilities
> will no doubt arise, and it would be nice to have less overloading of the
> text and presence capabilities by allowing this 'foot in the door',
without
> opening up the floodgates!
> 
> On the other hand rather than opening up kludge-y new channels and tricks,
> you may feel these cases are already catered for... yet I could only deal
> with these in my mind after looking at JEP 0045 by a bit of 'creative
> bending of the rules', so I thought it would be worth raising them before
> the Nov 11th 2002 deadline.
> 
> Many thanks...
>  Marc Eisenstadt
>  Knowledge Media Institute, The Open University, UK
>  HOME OF OPEN SOURCE BUDDYSPACE = http://buddyspace.sourceforge.net



More information about the Standards mailing list