<inserted> scribenick: kaz

(some discussion about expectations for today's call)

cpn: we used to have discussions before the IG calls
... and it was useful

kaz: mentions some topics/features should be added to the use case description based on some template

cpn: right
... we already have good materials and would like to see the common ground
... for the best use of our IG conference time
... maybe we can share the presentation materials beforehand

<xfq> +1 to this suggestion

cpn: to have specific conversations to reach some kind fo decision during the IG call itself
... we'll get the details on the technical details as well

pal: what would be the next steps then?

cpn: Huaqi has shared some update on the list
... that's something else to see
... give an update during the next calls
... to have status report, etc.
... we need to review the latest update from Huaqi

<xfq> it would be good to make the goal and scope more clear to make progress more efficiently

cpn: I myself haven't seen that yet, though
... could do during this call today

pal: ok

kaz: are you showing the latest slide?

pal: right
... (shows Huaqi's latest slide)
... there is no standard required here?
... (about "Bullet Chatting Logical Architecture Diagram")
... this is a browser here
... (about "Clients (Browser, App, TV, etc.)")
... what about some possible TV API between the client side and the server side?

lz: it's a browser api
... only in the browser

pal: yeah, that's why I'm asking
... browser api is for browsers
... what about tv apis?

lz: browser apis can use dom and css
... tv-specific apis are not needed here

pal: what about bullet chatting?
... there is a browser within a TV
... processes "DOM + CSS + JS"

lz: right
... there is no native api

cpn: you can do web view

lz: yes

xfq: currently some of the mobile apps use native apis for rendering bullet chats
... if the implementation quality is good enough, people would use web view

pal: web view api is dom/css/js
... that's all what we have to do
... (about "Bullet Chatting Rendering Module")
... within this diagram, no standard is needed between the server and the bullet chatting data module
... also between the bullet chatting data module and the bullet chatting rendering module

kaz: from your viewpoint, what is missing and what to be added here within this diagram?

xfq: standardizing the rendering?

cpn: low-level rendering capability?
... or standardizing some higher-level rendering capability?

xfq: not really sure about the layer-model at the moment...
... thought about higher-level HTML
... but low-level apis may also useful

cpn: maybe would be helpful to see individual component each by each

kaz: ok

fd: Q&A slides
... Q&A (6)

cpn: Nigel is asking about broadcast tecnology

hs: not such a use case

cpn: so, only for internet streaming so far
... ok
... this is Francois' point as well
... different service providers agree on the data format

fd: in the future

hs: there is no such use case at the moment

kaz: there is a possibility for all the providers A, B, C and D to share one specific standard data format with each other?

hs: right

cpn: for on-demand
... this (distributed data) could be webvtt
... for live streaming, you need maybe websocket interface
... also need standardized websocket (sub)protocol for bullet chatting interchange?

pal: it says "bullet chatting interchange file"
... not api

cpn: we could think about possible api as well maybe?

pal: the critical question is...
... is this really a file? or possibly an api?
... (about "Bullet Chatting interchange file")
... at the very first slide, it said file interchange was not needed
... but here it says interchange file here
... is api needed to render it?

lz: ok
... rendering has higher priority

kaz: do you mean you don't care about the method, file or api?

lz: yeah, currently we're thinking about rendering
... when we say "interchange file", that just means we need interoperability

pal: understood

kaz: in that case, we should say "interoperable framework" or something like that instead of "interchange file"

cpn: yeah, would be better to change the term

pal: so rendering capability first and then interoperability

cpn: yeah, would be helpful to prioritize what we want
... anything more about these slides?

pal: nothing

cpn: good to get clarification about this
... maybe we can use some time to explore rendering

pal: not sure the slides go into that detail
... good to capture the scope here during this call
... the next step to clarify the detail

cpn: where should we capture that?
... we have a TF wiki?
... can update the description

hs: we have prepared examples on the CG side

kaz: web site, wiki or github?

<cpn> TF wiki page: https://www.w3.org/2011/webtv/wiki/Main_Page/Bullet_Chatting_TF

hs: wait a minutes

<cpn> https://github.com/w3c/danmaku/blob/master/USE-CASES/bullet%20chatting%20rendering.md

kaz: thanks!

cpn: this is great

kaz: we can think about the detail on what is missing and what we want to add

cpn: yes, there is a gaps section
... think Pierre made a good point
... understanding the rendering capability
... to achieve
... so wondering if some good description about rendering requirements here

API proposal

pal: there is a proposal document on the CG repo as above

cpn: proposal for browsers?
... adding bullet chatting element
... and browser support

lz: yeah, that would be ideal

cpn: how to connect this to data

xfq: data from the server?

cpn: how to identify bullet chat information?
... my initial reaction is
... would be difficult for browser engines to implement bullet chat element...
... two specific for browsers to handle
... so wondering about another possibility myself

pal: my impression is similar
... browser vendors are reluctant to content-specific extension
... prefer low-level extensions to cover high-level capability
... control more consistency
... setting a goal for new API and new DOM element would be very ambitious
... modifying and improving CSS feature would be possible
... but introducing a brand new API would be difficult

<inserted> similar to apache vs service worker

fd: generalizing things
... putting the date to cue would be useful

cpn: I'm seeing here
... media synchronized animation
... when bullet chatting comments appears
... causes the animation
... could be more generic
... not for the bullet chatting

<cpn> scribenick: cpn

kaz: automotive group tried to define vehicle specific HTML elements, but gave up and switched to a lower level approach using web sockets and microservices
... service-specific APIs or HTML elements may not be welcomed these days, could be better to define a generic interface, based on TTML or WebSocket
... we can think about the requirements more, how can these be solved through generic approaches

pal: it would be great to have a one paragraph description of the scope and objectives for this project, we can share with the IG

kaz: also, more detailed requirements before gaps

cpn: suggest giving a short progress update during next MEIG call on May 5th
... and we can organise another call for the bullet chat TF to look at rendering requirements and gap analysis

kaz: we can have a doodle poll to decide time slots, if needed

<kaz> [adjourned]

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/servier/server/
Succeeded: i/gene/similar to apache vs service worker
Succeeded: s/queue/cue/
Succeeded: s/cpn: yeah, analyzing vendors requirements first//
Succeeded: s/rrsagent draft minutes//
Succeeded: i/(some/scribenick: kaz
Present: Kaz_Ashimura Huaqi_Shan Larry_Zhao Pierre-Anthony_Lemieux Peipei_Guo Francois_Daoust Fuqiao_Xue Yajun_Chen
Found ScribeNick: kaz
Found ScribeNick: cpn
Inferring Scribes: kaz, cpn
Scribes: kaz, cpn
ScribeNicks: kaz, cpn

WARNING: No "Topic:" lines found.


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)