[Standards] Fwd: Radical Solution for remote participants
How much of this stuff can we do already? I know that much of (6) has been implemented in military clients, and I suspect (2) is an application of Jingle. (7) smells like a BOSH app, or some kind of a bot with a web UI. -- Forwarded message -- From: Douglas Otis doug.mtv...@gmail.com Date: Tue, Aug 13, 2013 at 2:00 AM Subject: Radical Solution for remote participants To: John Leslie j...@jlc.net Cc: IETF Discussion Mailing List i...@ietf.org On Aug 12, 2013, at 1:06 PM, John Leslie j...@jlc.net wrote: Janet P Gunn jgu...@csc.com wrote: Again, it strengthens the case to get it done right. This part has been working well though. Not necessarily. There was one WG where I had to send an email to the WG mailing list asking for someone to provide slide numbers on jabber. ... and Janet was merely the one who _did_ so. Others did their best to guess at the slide numbers. At least one-third of the sessions I listened to failed to provide all we are told to expect in the way of jabber support. :^( OTOH, we _do_ get what we pay for; so I don't mean to complain. Dear John, You are right about getting your money's worth. In the case of remote participants, they are charged nothing and receive no credit for having done so. Often their input is ignored as well. A radical solution for meaningful remote participation is to change how A/V in meeting rooms operate. This change will require a small amount of additional equipment and slightly different room configurations. 1) Ensure exact digital interfaces driving projectors are fully available remotely. 2) Ensure Audio access requires an identified request via XMPP prior to enabling either a remote or local audio feed. 3) RFI tags could facilitate enabling local audio feed instead of an identified request via XMPP. 4) In the event of the local venue loosing Internet access, the device regulating A/V presentations must be able to operate in a virtual mode where only remote participants are permitted to continue the meeting proceedings. 5) Important participants should plan for alternative modes of Internet access to remain part of the proceedings. 6) Develop a simple syntax used on XMPP sessions to: 1) signify a request to speak on X 2) withdraw a request to speak on X 3) signify support of Y 4) signify non-support of Y 5) signal when a request has been granted or revoked. For local participants this could be in the form of a red or green light at their microphone. 7) Develop a control panel managed by chairs or their proxies that consolidate and sequence requests and log support and nonsupport indications and the granting of requests. 8) Chairs should be able to act as proxies for local participants lacking access to XMPP. 9) Chairs should have alternative Internet access independent of that of the venue's. 10) Establish a reasonable fee to facilitate remote participants who receive credit for their participation equal to that of being local. 11) The device regulating A/V presentations must drive both the video and audio portions of the presentations. A web camera in a room is a very poor replacement. 12) All video information in the form of slides and text must be available from the Internet prior to the beginning of the meeting. Regards, Douglas Otis
[Standards] Vcard4 implementation in Movim
Hi ! I see that the XEP-0292 has been deffered but I think that XMPP really need a descent and modenr vCard support so I will implement the XEP in Movim using the PEP specification. We really need to forget vcard-temp now and go ahead. If you are an XMPP developers I invite you to do the same :) I don't think that there's any change to do server-side ? It's just a simple PEP node for me. Can you confirm this (or not) ? Tim
Re: [Standards] Vcard4 implementation in Movim
Hey, The transition to vCard4 could be made possible by having one single vCard module that would handle both the legacy vcard-temp and the newest vCard4. The module would put an abstraction layer over the legacy vCard thing so that it can handle/serve the set/get for vcard-temp also, while storing and managing database vCard data as if it was all-vCard4. Then, the clients still storing vcard-temp (that said, all the clients available as of today - except OneSocialWeb and probably BuddyCloud), would not have to be updated so that the vCard4 compatible clients can retrieve the proper/new vCard4 of an user only storing vcard-temp. We are really looking forward to implementing vCard4 XEP in Jappix, too - as we work closely with the Movim team! We can also look into making such an hybrid Prosody/Metronome module to handle that idea. Cheers, -- Valérian Saliou Jappix FrenchTouch Web Agency founder. Uno IM product lead. More about me on my personal page. On Aug 13, 2013, at 7:01 PM, Peter Saint-Andre stpe...@stpeter.im wrote: On 8/13/13 8:01 AM, Jaussoin Timothée wrote: Hi ! I see that the XEP-0292 has been deffered but I think that XMPP really need a descent and modenr vCard support I completely agree, which is why I authored XEP-0292. IMHO it needs only a few small fixes (the XSLT is incomplete). I will commit to updating it by the end of August. so I will implement the XEP in Movim using the PEP specification. That's great news! Please send any implementation feedback to this list. We really need to forget vcard-temp now and go ahead. +1 :-) If you are an XMPP developers I invite you to do the same :) I don't think that there's any change to do server-side ? It's just a simple PEP node for me. Can you confirm this (or not) ? For the IQ-based storage, some server-side changes would be needed. However, as I understand it many server implementations don't use vcard-temp as the native data storage format anyway (or, if they did, they could run vcard-temp data through a corrected and complete XSLT to serve up vCard4 data). Maybe I need to work on this for Prosody... ;-) Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME cryptographic signature
