On Thu, Mar 3, 2011 at 5:07 PM, Peter Saint-Andre <[email protected]> wrote: >> I have only one comment at the moment. >> >> I would not like to drop support for group-chat.
Group chat is doable as a private extension to any standard I will introduce. I might even work with specific parties who might decide to introduce groupchat. People here who received my "Supplement" Word document showed that there were 2 or 3 pages of groupchat issues that needed considering (I didn't mention those in the submitted standard) -- email me privately for a copy. I think at this stage, it's pretty plainly clear that groupchat complicates the standard sufficiently enough to downgrade it to a single-line bullet into an "Future Experimentation" section. It was never fully documented in the submitted standard, and I warned about its experimentalness. > (I would sometimes find chat state notifications useful, e.g. during a > meeting of the XMPP Council when I really care whether one of the > Council members is about to post a message to the room. Right now I > can't think of a time when I would want real-time text in a chatroom, > but I can envision that deaf people might think differently.) If 10 people started typing at the same time, it will be quite distracting. But it does automatically discipline people to type only one or two people at a time (if they were doing construction discussion). On the other hand, I can envision a "lecturer" / "teacher" / "leader" being allowed to send real time text, with everyone not sending real time text. That would be useful in disabled classroom situations, where anyone can pre-compose questions and only send them if necessary. That said, I do intentionally design my protocol to be compatible with a theoretical / future / private groupchat extension. I never really defined how groupchat works, and when fully explaining the scenarios (moving content from the Supplement document to the spec), it increases the spec size to larger than the spec that I originally submitted. One of my two software packages utilizes a >2 realtime text groupchat, so it will definitely use a private groupchat extension. Right now, it's running on a proprietary protocol but I'd love to convert it to XMPP Real Time Text with a groupchat extension (even a private groupchat extension). This software I wrote, is a project that has existed from long before I started writing the XMPP Real Time Text spec. If there's big demand for interop, we can consider a standardized public groupchat extension later. The point is that my standard doesn't preclude ability to do groupchat extension.
