[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.
  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
> 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
> and (ii) (nearly)simultaneous voting in a multi-user chat. The more
> issues concern, in case (i), timing, syncopating, or what I prefer to
> of as 'metronoming' of group behaviours, e.g. 'Quiz 29 (or breakout
> 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',
> 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