Meeting minutes
Introduction
ChrisN: Two things on
the agenda, TV application development
… and then look at our TPAC plans
TV application development
<tidoust> PR 86 - Web development experience charter pull request
ChrisL: Performance on
TVs is difficult. Mobile is a comparison, that was difficult
because of slow devices, no longer the case today
… But TVs still slow compared to mobile
phones
… Another topic is the developer
experience
… We have a problem statement on development
experience
… I think it would help developers to have a
standard way to load development URLs on a TV
… There are many manufacturers, each has its own
developer experience
… Typically the flow is to go their website, create
a developer account, link your device, go into the menu and find
the developer mode setting
… then go back to the developer portal and upload
your site, then hope that your site loads on the TV
… sometimes it needs packaging up. Testing across
multiple TVs is difficult and time consuming
… So how to make it easier, have a local dev
environment you can load on the TV
… Chromecast has become ubiquitous, can cast to TV
from a button in a website
… If we can get the same functionality, copy a
local URL and port, load into the browser with debug tools
available, would be a fantastic experience for
developers
… Enable more people to be involved in building
applications. This can be done together with the performance
stuff
… Comments received: creating new APIs, to know
you're on a TV, HDR, changing linear channels, audio configuration,
Dolby 5.1 or surround
cpn: Purpose of this
document is to scope some work around developer experience on TVs.
Very useful thing to do to invite more participation and setup
goals.
… So first, thank you for preparing
this.
… Introduction focuses very much on that developer
experience you're describing.
… However, the list of topics is much
broader.
… If the intent to focus narrowly on the developer
experiences or to address the list of topics?
… If the latter, we should adapt the
intro
ChrisL: Two pieces we talked about: development experience, and APIs for performance
cpn: I agree it can all
be in the same document. Personally speaking, the slightly broader
scope is helpful.
… Interested to hear views from people in this
call.
Piers: I don't get
heavily involved, but in the HbbTV world there are developer
resources. How does this intersect?
… There's the HbbTV web APIs and the web browser
app that runs on the TV, doesn't have the same
environment
… So issues around which environment you're
using
… And a third component is the media engine, which
can be separated from the APIs. Some of the state and HTTP based
information can differ based on which entity is making
requests
Kaz: Thank you Chris
Lorenzo for bringing this problem statement
… I think we should see some more implementations
and deployment of web based media distribution globally. My
suggestion is to include that kind of survey in scope
… We can generate a more detailed problem
statement, and think about our requirements and expectations, about
making things faster and so on
… And then some kind of existing workarounds or
extensions for web based media distribution as well
… Can vary between different regions, US, Europe,
Japan. Think about potential solutions, and get ideas from a
survey
Andreas: The approach
should be cross environment, Hybridcast, HbbTV, manufacturer
specific environments. Where is the best place for the standards
activity, where does it fit?
… Is the problem the same for IoT devices, not just
TVs, so an even broader scope?
Nigel: You don't
mention WASM. People are talking about using that to create user
experiences that are more performant
… Would that change the problem statement at all,
or is it orthogonal?
ChrisL: WASM doesn't
really change the scope. It would still run in a browser, so the
developer issue of loading the URL still exists
… On the performance topic, WASM definitely changes
how we develop apps. Some companies are experimenting with it, WASM
with WebGL for rendering
… But the downside is that it's still new, so not a
lot of examples or developer experience with it
Nigel: About testing, do you also think it's useful to have test drivers that work across different TVs
ChrisL: It's critical, WebDriver is supposed to handle that, it should be in scope, to automate TV browser navigation
<Zakim> nigel, you wanted to ask if the use of WebASM impacts this problem statement at all
JohnRiv: On WASM, one think that came up for Web Media API snapshot, is some TVs are only 32bit, so can't have full support
Hyojin: Thanks for
sharing the problem statement. On the developer experience, it
depends on the underlying platform
… Mobile app development has similar problems.
Tools such as emulators and remote inspectors
… For embedded platform cases, it could be provided
by the platform side. The background section of the document has
several ideas to be considered
… If you have any proposed API for those we could
discuss in GitHub issues
… In potential topics, I'm interested in the TV app
store topic, but not sure who can drive creating one
… Could W3C or other alliance do that? Could
consider PWA as a packaging technique, we could go into that
subject in a separate issue
ChrisL: That's great,
PWA, I'd be happy to present on how that's evolved on the mobile
web side
… Makes sense for TV apps if we can have a single
way to package apps and have one store to submit to
… There are a few PWA stores out there for
different OSs. Don't know what conglomerate we'd have to make to
use one app store, but a good topic
Hyojin: The most
challenging thing from an embedded platform point of view, is that
for us we haven't supported the functionality for now, so PWA
requires some platform adaptation work
… Have you considered how to apply PWA in the web
app environment?
ChrisL: Need to talk
about how it would work, e.g., Service Worker for offline mode. If
we set the standard now, hopefully TVs would have support built
in
… But not be backwards compatible for all
TVs
Hyojin: As far as I know there's no TV platform that supports PWA right now, but they may have considered it. We could discuss it in the future
cpn: thanks, btw,
regarding Andreas' question about where to have the
discussion
… what we should do is we as the W3C MEIG work with
the related SDOs like HbbTV, ATSC and IPTV Forum
… who use our technology and extend it based on
their requirements
… how much they're interested is
important
… need to look into the scope
Andreas: It would be
good to talk with those organisations and get some feedback
… Could have a joint meeting. Discuss more details
beforehand, but would be good to ask those organisations about
that, and the proposed solutions
cpn: agree
… make it broader than the current text but not too
broad
… may need iteration
fd: W3C should be the right place to have the discussion :)
cpn: one of another
topic came to mind
… perhaps should look at APIs for media streaming,
etc.
… good presentation at a conference
… from the people have experience on media
handling
… that's something interesting the group may want
to help
… wondering if we'd extend the scope of this
proposal
… if there is interest, welcome to see
it
… to facilitate the discussion
Kaz: During the MEIG
chairs calls, we've discussed making a dedicated TF for these
issues, then think about how to solve the problem, and what kind of
document might be generated
… I'd suggest we start with task force charter
generation, focusing not so much on the specific problems, but
define the scope in general
… There's an example ME TF charter
<kaz> e.g., Media Production TF
ChrisN: We can put into a similar structure. Next step is to refine the document that Chris started, people are welcome to reply to the pull request
Kaz: My impression is that people here are interested in the topic. Add clarification for further discussion
ChrisL: I'll remove the TV API support and make that a separate item. So developer experience will be: loading the development environment and packaging for production release (PWA)
cpn: we've identified
three big items here
… do you want to initiate discussion for each of
them?
… or start with some specific focus?
ChrisN: Three areas: Development experience, app performance, and TV specific APIs
ChrisL: Performance is somewhat unclear on what the solutions may be. Benchmarking in WAVE group. Focus for now on simplified developer experience
Kaz: I agree with
ChrisN. There are several possible next steps, we can handle web
performance issues in general, or another possibility is choosing
one or other items to concentrate on such as TV API
… My understanding was discuss performance again,
and clarify the problem statement based on people's input,
including related SDOs
… Then think about detail of those topics, API
definition, later
ChrisL: This is the
survey idea, three potential topics, could do them all if there's
interest from the community
… I'm interested in them all
<ChrisLorenzo> List of Topics Loading development URLs on TV Packaging TV apps using PWA standards Performance benchmarking TV APIs needed
Kaz: If some participants are interested in one topic or other, concentrate on those at that time
ChrisN: I like the idea
of focusing for now, but capture all suggestions
… Thanks all for your input, we'll refine the TF
scope and come back with next steps
TPAC planning
ChrisN: GH issue for
planning: https://
… We'll have a single 2-hour dedicated MEIG
meeting
… Then other meetings during the week, joint
meeting with Media WG and WebRTC WG planning
… And TTWG and Media WG both meeting
… So what include in our MEIG meeting
agenda?
… Could get into more detail on the topics from
today's call
… Other group joint topic suggestings?
JohnRiv: Typically WAVE
gives an update, so we can talk about stuff. Can look at additions
to Web Media API snapshot
… Work being done on tracing, related group in
W3C
ChrisN: Will follow up with you on that
Next meeting
ChrisN: August 2, 3 weeks from now
[adjourned]