Re: Bullet chatting interchange format was:

Hello all,

  Since there are  still some questions left over from the last meeting about the "Interactive Wall” use case, so I wanna make a small comment on it and try to make it clear :-) 

  First, I would like to briefly explain what “Interactive Wall” is. Let's say you have a laptop connected to a LCD display with a HDMI cable. Under this circumstance, the laptop is your primary display, and the LCD display is your secondary display.

Now you open a browser (Firefox, Google Chrome etc.) and open an HTML file, then drag the browser to the secondary display and make the browser to enter **FULLSCREEN** mode to hide the browser menu and address bar. 

The HTML file mentioned above is very simple, it contains **NO VIDEO** and just some comments or tweets. it can load the comments or tweets at regular intervals by using Ajax or WebSocket from remote server and render the comments in the “Bullet Chatting” way. This is how the “Interactive Wall” scenario works.

You may wonder how the user sends comments to the “Interactive Wall”. It depends. As long as the remote server exposes some sort of HTTP API (REST API etc.), you can send comments in various ways. For example, we can have another HTML file and there is an input field in it, users can type text and click the enter button, and send the comments to remote server. 

Now let’s return to the “interchange format” topic. In fact, “Interactive Wall” is a Bullet Chatting *rendering* use case, not a use case for “interchange format”. Of course, “Interactive Wall” can leverage the “interchange format” to do the rendering, since there may be color and other styling options in the “interchange format”. 

“Interactive Wall” is a special scenario, there is no video in this scenario, and we found few cases in native apps (Android, iOS etc). We are actively listening to community feedback. This use case does not bring new technical requirements (it can be achieved with simple HTML/CSS/JavaScript code). It is a non-video use case used in browser (we're not aware of any non-browser implementations for this use case), and it is not a common use case comparing with the video use cases, so if it causes a lot of confusion, and we can remove this scenario from the use cases document if necessary. Highly appreciate your feedback!

Best wishes.

— Larry Zhao


> On Jan 10, 2020, at 02:13, Pierre-Anthony Lemieux <pal@sandflow.com> wrote:
> 
> Pierre