Short introduction of attendees
<ted> https://www.w3.org/auto/wg/wiki/TPAC2017#Monday
<ted> Summary of activity (first half of slides)
<ted> Patrick: we'll be delving more into RSI on Thursday
Patrick: PatrickB took a look at
HTML5 as a UI for IVI
... he found that it was needing more and more a structured
interface
... often it was coming down to elements and attributes,
addressable by URI
... it is easy to use this structure from various
languages
... if you want to be abstract on CAN bus, it can be
represented in key/value pairs
... it is build on top of HTTP
... we will discuss openid and oauth on Thursday
Ted: We heard RSI (ViWi) was in 10s of thousands last year, maybe hundreds of thousands now and soon millions
Patrick: not sure the numbers at present. it is the protocol for future generation vehicles
Ptrick: it would be good to have a single protocol that can solve both needs
Linda: where can I find out more about the payments work?
https://github.com/w3c/automotive-pay/wiki
Ted provides introduction to payments and fueling workflow
Patrick: location and trust are
the key components as you described
... in Germany you fill up before paying
Ted: use to be the same here until gas prices spiked and people started stealing gas
Gururaja: Bosch is observing the proposed W3C direction at this point
Wonsuk: we're focusing on VISS more right now but for payments we're thinking REST may more sense for some use cases
Caleb: this seems like a card present transaction instead of online not present model
Linda: depends on the merchant service
Rudi's email to Auto WG on VISS and ViWi
continue with VISS, explore signals and other convergence points in BG
PLH: your charter is running out at the end of the year
<Paul> Philippe Le Hageret here for recharter
<Paul> Ted to talk with Lovene and company tomorrow.
<Paul> Good to get automotive alignment
<Paul> Understanding one year ago... Presentation from VW... Here at Hyatt. VW Presnted RSI
<Paul> VIWI
<Paul> Decide to have Task Force and conversion.
<Paul> Continue with VISS
<Paul> Need to ask for exension or recharter
<Paul> Ted: Goals to gain implementation experience with VISS. E.G. Sanjeev Ba doing OCF
<Paul> Moved toward CR. Got widespread review from W3C and GENIVI. Down to one issue. How to handle host name. How is service found/discovered.
<Paul> Patrick, Rudi and Ted met and have discussion that will be a negotiation.
<Paul> RSI has other domains in addition to signals
<Paul> Typically charter every 2-3 years.
<Paul> Question is do we extend or recharter?
<Paul> In other words have VISS become RC or do we want to attack other domains.
<Paul> Discussions with Philippe and others the question is should we recharter or?
<Paul> RSI is being implemented by LG, Samsung, MELCO
<Paul> Philippe
<Paul> Experience with specs that take a long time.
<Paul> Do we want to take VISS to Rec or?
<Paul> OR should we shift energy to v2
<Paul> Nothing wrong with either side... It is really what will get legs in the market.
<Paul> If the group keeps insisting that VISS to REC
<Paul> run high risk
<Paul> Suggest coming out of this TPAC what the next charter should be.
<Paul> Ted -
<Paul> How fractured and fragmented how the marketplace is.
<Paul> Want to gain consensus and move forward with other automotive OEMs, Tier1s etc
<Paul> Urata-san has great test suite we can use.
<Paul> Can merge the two.
<Paul> RSI -> VISS
<Paul> Need more than just signals.
<Paul> Common arch/model that can apply to other domains.
<Paul> Where do we want to be in 2020
<Paul> Risk getting in broader market
Paul: it comes down to industry marketshare and we need to cast a broader net
<Paul> Ted: If no adaptation ?
<Paul> Patrick: If JLR ready to implement then go through with Version 1
<Paul> Patrick: Trust in specification is something else. Something official that represents the current state of the working group.
<Paul> Philippe- Some of the market is implement v1 than we do not necessarily need to take to rec.
<Paul> Ted: Procedurally will not change VISS to a note until formal fixes.
<Paul> Ted: Ask Adam for opinioin... Meeting with Lovene tomorrow. Not a done decision but get feelings or direction.
<Paul> Adam: I caught the last couple of minutes
<Paul> Ted: Quick recap
<Paul> Adam: Would VISS and RSI be compatible across all versions
<Paul> Ted: VISS signal tree most important.
<Paul> Ted: Decide on data model. Still have sockets. Backward compatibility a ship. Map methods, etc...
<Paul> Adam: Because VISS is relatively agnostic to a data model should be able to support other formats
<Paul> Ted: Data model a big piece. Since VISS does not have URI will be an addition.
Paul: I want to hear others' opinions
<Paul> Patrick: They have tree pass that could be considered a URI. Just a path through a tree. Tree is rep
<Paul> Ted: Engage Caleb
Caleb: I want more context before I could give opinion
<Paul> Wonsuk: complicated. Difficult to say.
Wonsuk: some companies want to
use these (VISS/VIAS) specifications
... we have invested time in them
<Paul> Wonsuk: If we made spec that are to be deployed in the market we need to seek companies who would use specs. Candidate is Jaguar. Had a lot of time with both spec so far
<Paul> Wonsuk: Why make spec if we just make a note
<Paul> Philippe - How long to rec
<Paul> Philippe: Charter at end of year. Extension or rechartering.
<Paul> Wonsuk: Does not think that is the issue. One of the issues is how to align existing specs and RSI specs.
<Paul> Philippe: if we can recharter on aligning the two why not?
<Paul> Wonsuk: Big issue is data model rather than API.
<Paul> Ted: Patrick Bartsch and Rudi will work on aligning data model.
<Paul> Ted: Rudi owns that repo.
Paul: as you noted Genivi is heavily invested in this stack and they will be interested in the data model
<Paul> Ted: Rudi part of arch group.
Paul: when you look at vehicle
signals, you are looking at distinct and discreet bits of
data
... they will look at the cost of eg mapping from an embedded
engineer perspective whereas a web developer looks at how easy
it is to assess and doesn't concern themselves with underlying
performance
... a common model is needed for V2x and ADAS as well, they are
different problems
Patrick: we are trying to get across things that are not changing that rapidly and have a high degree of complexity
Magnus: are they solving the same
use case, partially they are
... my understandin of VISS is a way of forwarding or exposing
vehicle signals
... from my point of view it is a bit different but not
mutually exclusive. RSI as a superset and VISS a subset but
again data model should be consistent
Patrick: we have a single
protocol that can serve both needs
... we want to bring these two sides together
Paul: we should ask the question of whether we are trying to solve the same problem or different
Patrick: short answer is yes,
trying to bring vehicle data from a to b
... depends on the scope of the problem definition
... VISS case was primarily for data attributes from CAN bus
whereas RSI was for providing data in general for multiple
domains - including media
... having an additional access method in the vehicle seems
counter productive
Magnus: you describe this as a
microservice architecture
... VISS could be one of those microservices
Patrick: one of our services is the vehicle data service
Paul: RSI can use REST and WS at any time, VISS can allow you to grab any handful of signals through socket at any time
Caleb: you mentioned it is a graphml implementation
Patrick: similar
... iirc graphql is a way to work with graphml
Caleb: there is also a
subscription model for latent and frequent signals
... that seems like the primary use case for this,
distinguishing what elements you want how
Urata: basically we were working
on JLR proposal and I think VISS is getting somewhat mature,
maybe 70-80%
... the goal is near to get to REC
... regarding ACCESS & KDDI, we were following the WebIDL
proposal fron Kevron Rees from Intel
... the change of direction to VISS was somewhat reasonable. if
we change direction again, I want a strong reason
... I want technical reason that is understandable
... JLR and VW specifications are trying to achieve basically
the same outcome
... I am not sure why to make the change
... if JLR does not want to push for continuing VISS then I
would be more accepting
... the data model is important
... as Adam said VISS is agnostic on the data model
Adam: we fully intend to push
VISS through and feel we are snagged on the one issue
... we are exploring with suppliers, getting this into future
products
... we want VISS
Hayato: difficult is the priority
of which specification
... ACCESS & KDDI have worked on VISS
... undecided
Linda: no opinion, more interested in web payments
Ted: Sumie, would you like to give your impression as well?
Urata: she is ovserving many groups and I think not having strong opinion on detailed issues.
Ted: we welcome the opinion of all attending this meeting
Exchange in Japanese between Urata and Sumie
Urata: Sumie wants a recommendation at the earliest stage
PLH: how long do you think it will take VISS to REC?
Urata: not many remaining
problems
... maybe 3-4 months for VISS
Hadley: I want to hear about the group dynamic with these two approaches
Paul: this is more Genivi+JLR vs VW approaches. people are not entrenched so much technically as they are business
Hadley: why we (TAG) pushed for
REST vs bespoke (web socket) API was scalability
... interesting to hear how you are thinking about trying to
solve these problems
... there is a mindset difference between a manufacturing
perspective and decide something for 15 years versus how to be
adaptive with needs
Daniel: that is part of the web
philosphy at large
... is this to create a more open webby ecosystem and which is
more weighted along those lines since that should be an
influencer
Caleb: good point, which is more
easy to consume. REST is more dominant in the Web as is self
discovery APIs which again REST is a benefit
... maybe less efficient for rapidly changing signals
Hadley: you get efficiencies on a different scale
Caleb: most expensive cost is the developer
Magnus: I think just considering
web developers and their applications is limiting the
conversation
... as as Tier 1 exposing said signals from varied OEMs. they
need to be tranformed, parsed and transmitted
... within the car, we are looking at those use cases as
well
... there are slightly different problems these approaches
solve. I understand you have REST and sockets
Patrick: yes, the socket is when you need to be notified of a change
Magnus: data model the same between REST and WS?
Patrick: yes, same structure
Magnus: regarding converting it to a Note, that is kind of saying you can have it but it is deprecated
PLH: no it is not
deprecated
... we do not have an official recommendation for CSP1 yet it
is widely deployed (in all major browsers)
... there are plenty of examples where things less than full
REC are implemented
... in this case your estimates were missed so skeptical about
being able to be done within 3-4 months which doesn't take into
account the W3C process and patent disclosures
... we can declare victory on v1 but put energy on convergence
with a v2
... clearly market is not going to be able to use the v2 right
away so there will be lingering interest in v1
Magnus: time to market for auto
is rather slow so yes 1-2 years is expected
... VISS is a subset of RSI as I understand it and the result
will be somewhat different. RSI can support more use cases out
of the box
... VISS can handle it
... I don't see a big technical reason for closing work on
VISS
Ted: work can continue if eg there is an issue, regardless of the doc status as a WD, CR or Note, fixes can be made. send a pull request
Dan: what I think would be
interesting here is how the Web can be a force in opening up
this ecosystem
... we have seen this with smartphones, now with TVs
... it does feel like there needs to be a roadmap and how
things open up to 3rd party developers
... I might not like the dashboard that shipped with my
vehicle, i might want someone else's
Ted and Paul: it won't be an open marketplace, controlled by OEM for liability/safety reasons but market forces for popular apps or dashboards could pressure OEM to allow them on their marketplace
Patrick: we want everyone to be
able to developers
... we have things like distractability to consider
Hadley: my previous understanding was this wasn't for mission critical systems
Ted: correct but safety and review is necessary
Gururaja: we need to focus on a
clear data model. when can an application access a signal
... is a REST approach a detriment to performances for some use
cases
... when it comes to a head unit there are many other
components, REST may be better for some of the other areas like
WBS
... a gap analysis would be worth doing
Caleb: is WS better than REST?
Hyojin: I don't have a strong opinion as Urata mentioned it would be worth continuing pending time constrants
Janina: there are many people who
are excited about what is taking place in automotive
... there are not any accessibility specific concerns raised
yet
Judy: I'm the director of WAI at
W3C, Janina leads the accessibility horizontal review for all
of W3C's standards
... we also produce guidelines. often people think a11y doesn't
apply to their standards work initially when it should be taken
into consideration
[Introductions around the room]
Ted: we are being joined by Janina Sajka and Judy Brewer on Accessibility. While we are defining services and not UX APIs we may still want to consider collaborating with W3C's Web Accessibility Initiative (WAI) on guidelines. People with varying needs are going to want to be able to pair their devices with vehicles to gain information and interact with it. Distractability is a major concern for applications on the head unit and WAI has various work on multi-modal that may be very applicable to that area.
Janina: I am particularly
interested in autonomous vehicles but also need to give thought
to the incremental changes we will be seeing in the
industry
... I want to hear if people are still looking at a model of
having a vehicle customized to their needs
... we are seeing a new model in the industry, usage versus
ownership
... when you think about usage model, the accessability needs
increase. for someone with needs you are relying on the driver
completely
... you have to think of the transition from the vehicle
transportation to the next point, where you are letting someone
off and where they need to go next
... for a blind person taking an autonomous rental car how do
you inform them when their vehicle arives?
... blind users are extremely excited about the possibility
Patrick: autonomous driving was
not yet on my mind at all. for what we are discussing (at W3C)
all we are working on is user interface
... I see the benefits of an abstract representation and how to
make that data available
Janina: we dealt with that in ARIA with min, max, increment
Patrick: I have no grasp of what is lacking
Ted: autonomous vehicle interactions are likely to be more directly coupled and not go through any of the specs we are working on, however think of a blind person wanting to use their device to direct the car instead of needing to learn a vehicle specific UX. That can leverage our spec work
Janina: there are varying
disabilities such as cognitive and difficulty with eg numbers,
they would require a different interface
... we need to think about the incremental improvements and
should check back in
... also think about the aging community
Judy: there is an assortment of disabilities, Janina mentioned some. there are also adaptive ones for physical needs
Ted: instead of custom controller hardware needing to be permanently integrated into a specific vehicle, the user can bring their device and pair with any vehicle that supports these standards
Patrick: a software solution could replace the current hardware ones as well
Judy: what is the term for the individual in an autonomous who would be the navigator, responsible for the vehicle's direction
Patrick: we see every passenger
as equal in that model
... there can be right restrictions for eg a bus where route
and stops are predetermined with no local overrides
... for hailing a vehicle I see fewer buses and more vehicles
available for individuals. if you have specific needs then type
of vehicle can be requested from a communication device
Janina: and a way to tell me when my particular vehicle arrives, eg a specific tone
Patrick: or vibration
Caleb: are there introspection APIs or annotations to allow discovery of features, to see if it able to lower itself or play a tone
Patrick: right now, there is no
discussion like that since there is no entity interaction
defined
... when describing what an engine looks like on a data/api
level we can go into detail now
... I do not have a model for defining eg an electronic
steering wheel right now
... there is a central db to see all that is available in a
system for a car, see what services are available and all the
data elements they expose
... it is discoverable
Magnus: the same applies to VISS, there is a way to ask what signals do you support
Ted: we are also granular on access, you may only get a subset of what is available for your specific application
Magnus: you have to bear in mind that you will not always be connected to the vehicle. your device needs to pair locally
Judy: two things to mention from
our other guidelines work is multi-modality and user
choice
... I hope many times deferring to the social situations from
the passengers, there would be times a single designated
authority for the vehicle could be identified; and also it
could be helpful to allow for different signaling modalities,
for instance for a passenger who is deaf-blind.
Patrick: we are learning quite a
bit now internally on multi-modal for graphical and voice
interfaces
... I am pretty sure I can build many interfaces with the same
protocols and data
... I am not aware of any situation where we had to extend
capabilities to handle additional interfaces
... we normally start with graphical interface and then work on
spoken. I am quite confident that we can create multiple user
interfaces
Ted: +1 to the need for a
"designated" driver - authority for where it goes
... next steps how about sending to me and
public-automotive@w3.org specific parts of ARIA or other
documents we should look at
... we can start a wiki or other to start collecting use
cases
... from the broader WG and those in the room we can see who
has time and able to contribute
Ted: aka the infamous issue 223
Ted: since we first
considered a static hostname it always seemed awkward and at the
outset we also considered discovery mechanisms.
... it seemed every time someone new came into this group, this piece stood out
like a sore thumb
... in the simplest case there is only one
service and one device (the head unit) connecting to it seems
over-engineered which was why people wanted to keep it simple. we
are hearing now there may be multiple services and also interest in
allowing devices on vehicle LAN to pair
... discovery also has challenges/concerns
DKA: so what about a discovery
mechanism, what are the concerns there?
... hardcoding is kludge
Ted: requiring each developer to implement
discovery in their code seems onerous especially in the simple case mentioned
... doing discovery at each reboot of the car or when application is
launched is a waste/delay. it also presents opportunity for a rogue device to broadcast mdns to hijack a
client application, steal its credentials and later impersonate that app
Hadley: a hardcoded hostname is still spoofable
DKA: PKI should help avoid spoofing
Ted: public keys for service will likely be self signed as public CA registry would have difficulty signing local host/IP cert not to mention. there is a breakout on Wednesday for that topic
Magnus: to me this should be implementation specific and not something that necessarily belongs in the spec
Ted: the group agrees discovery is the way to go but it opens up a number of additional potential issues
<hadleybeeman> Web of Things architecture: https://w3c.github.io/wot-architecture/#wot-client
Hadley: WoT punted on the issue
Ted: I have provisional approval from W3C Director for a w3.org hostname to get around .local issue, they would like to see a final proposal
DKA: what is the issue with .local hostname?
Ted: we have no right to lay claim to a .local hostname
Magnus: I don't see how putting this on w3.org solves anything
Ted: it doesn't, same issue as .local but the difference is W3C is SOA for w3.org and nobody owns .local
<hadleybeeman> See https://www.ietf.org/rfc/rfc6762.txt"9. Conflict resolution"
Proposed: organize a breakout session for Wednesday as issue is not unique to Auto, also WoT (deferred), Entertainment (eg 2nd screen)
[Separate breakout didn't occur due to conflict with Executive Summit. The topic did get some coverage in HTTPS with local CA]
Paul: can we simply put a note in the spec to allow people to choose for their vehicle implementations?
Ted: we could but that breaks cross vehicle app portability
Patrick: I was thinking of a central registry, a complete list of all services
Hadley: more of a traditional DNS instead of mDNS?
Patrick: yes
DKA: if you are talking about a registry then you need hardcoded names
Ted: I think for apps on IVI,
part of the install process can do zeroconf (DNS, mDNS or other) and store actual
local conf for an application to avoid having to do rediscovery
... that improves performance, reduces attack options. in the case
of smartphones or tablets, they would need to do discovery for
every new vehicle that app pairs with but could also
store locally after initial pairing
... also makes it so devs don't need to implement discovery per
application, the
app install framework handles it
... OEM can even ship the static conf for a given vehicle as
part of an app package manifest
Hadley: I encourage you to solve for broader needs and to be more flexible and forward thinking
Resolved: agreement vehicle should handle discovery but may ship or handle via implementation specific (or discovered on app install) configuration
Patrick: also interested in your (TAG) thoughts on mixing sockets and http
DKA: that or polling is how others are doing this on the web. There is also WebRTC data
Hadley: using WebRTC here would be kludge to
DKA: fetch may be replacing sockets
[discussion of HTTP2 connection limitations for our need]
DKA: that would be worth putting
in queue for broader TAG review
... web sockets seem to suit your needs
Caleb: problem is everyone
essentially creates their own unique API for interactions in
sockets
... some basically choose regular HTTP methods (GET etc) within
sockets
<hadleybeeman> Please put an issue here: https://github.com/w3ctag/design-principles
DKA: there are discussions in IETF beyond HTTP2, QUIC (continues on SPDY)
Magnus: what is the timeframe for that?
Ted makes snarky comment about how QUICk we went from HTTP1.1 to HTTP2
DKA: evolution is much faster
now
... it even optimizes some of TPC for HTTP
<hadleybeeman> Magnus: quic https://duckduckgo.com/?q=quic+udp+&t=brave&iax=images&ia=images&iai=https%3A%2F%2Fimage.slidesharecdn.com%2Fquicoverview-141102192659-conversion-gate02%2F95%2Ftechnical-overview-of-quic-5-638.jpg%3Fcb%3D1414956498
<kaki3> ・Extended Vehicle Methodology ISO 20077 & Extended Vehicle Web Service: ISO 20078 http://taysad.org.tr/uploads/dosyalar/18-12-2014-01-26-5-Extended-Vehicle---a-proposal-for-sharing-diagnostics-data-in-the-future-Scheiblich-ve-Raith-Daimler-27-11-2014.pdf
<kaki3> Can We use the host on the web instead of the local host?(VISS Server on Global Web) If yes, we can cover the use case of ISO Extended-Vehicle, I think.
<kaki3> (The story went side by side,Sorry)
Ted: first we should discuss issue 233 on whether VIAS should be a wrapper JS library or an API spec, getting some pushback on it going forward toward REC but agreement on encouraging lib development
[summary of how it came about, reasons for pushback]
Patrick: I was a big fan of a
convenience library for RSI initially, it is rather complicated
and have since changed my opinion
... not everyone will be using the same language (JS) so it is
for a limited audience
Paul: if people want to use one, they'll create it
Patrick: similar to current concerns for QUIC, it isn't widely supported in many programming languages at present
Paul: one of the reasons we
continued to talk about VIAS is that people may not want to use
REST or sockets but something more like a WebIDL API
... not sure it is right or wrong
... ACCESS had implemented the previous (WebIDL) approach
Urata: basically using VISS directly is ok but not as convenient as a JS library that we developed at the start
Paul: part of the discussion about the higher level api (VIAS) is that it does not *need* to talk to VISS, it could go directly to signals in some other manner
Urata: VISS is designed to use web sockets in the first place, later it could do HTTP
https://github.com/w3c/automotive/issues/233
Patrick: WebIDL is a browser
extension. now I can understand VIAS can be either a library or
extension
... that is interesting and makes sense. the problem is the
protocol you are using has to fullfill all the requirements of
VISS
... as we just discussed, there may be multiple, separate VISS
services (ECUs) providing set of signals
Paul: both interfaces need to be defined separately
[Patrick goes to the whiteboard, diagrams the complications of multiple path options]
Patrick: when you start defining
what a client wants and what a service offers, it has
possibility to clash
... you are the client of the user of the data
... I agree having something easier and more intuitive to a
developer makes sense
Paul: this can be either a WebIDL or JS library
Ted: W3C doesn't standardize JS libraries
Magnus: I have always seen VIAS as an implementation (of VISS client library)
Patrick: VIAS does not need to interact with VISS, it can have some other means besides sockets to access the information/data tree
Paul: it was originally conceived as a JS library and second thought was extension/WebIDL route
Gururaja: in Genivi we define things lower in the stack in Franca IDL
Patrick: they are not defining the data elements nor getSpeed but get(/engine/speed)
Paul: what is consistent is VSS
Ted: this is proposed as either
an extension or JS lib. the former is reasonable to standardize
at W3C, latter not and either is confusing
... there is a potential for competing libraries to come into
existence and may prevail in community over ours
<Paul> https://www.w3.org/TR/vehicle-information-api/
Ted: we are being encouraged to convert this to a W3C note and for making this (or other library implementations) available online in our github repo or point to external eg at ACCESS
[earlier Ted explained we are asked to reflect and can appeal proceeding but seeing resistence in doing so. W3C wants to avoid imposing on the group but may decide to block]
Ted: think also about the app
developer - how are they to know if they need to include a JS
library or if they will be running in a browser runtime with
built in VIAS support?
... app would have to be written in both flavors that breaks
cross platform compatability
Paul: one of the reasons we moved to a service approach is it was going to be challenge to convince more than a couple browser vendors to implement WebIDL
Hira: as Paul was saying we have
discussed and concluded VIAS is a high level WebIDL that is
agnostic about the underlying architecture
... I would like us to move forward on VIAS as it is
Patrick: why is VIAS important/desired?
Urata: it is a convenience API for developers, it can be a wrapper to VISS
Patrick: I agree a convenience JS
library makes tremendous sense
... I question if it needs to be formally specified
... I want to have it
Hira: underlying architectures will be up to OEM
Patrick: the argument makes sense as a browser extension but not as a library
Paul: if we remove JS implementation would that be acceptable?
Urata: we could remove that paragraph
Ted: we would then need at least two browser vendors to implement
Paul: Access, the others in this space are OBIGO, Genivi which is using Igalia
Patrick: I definitely want more
convenience and having it as a standard would be nice but not
required
... the underlying protocol is more important and a JS library
would be acceptable
Paul: one of the reasons we moved
away from WebIDL was the lack of browser vendor interest in
embedded vehicle platforms
... KDDI and ACCESS remained interested in WebIDL approach as
the group decided they wanted a service
... what we need is more support from auto manufacturers and I
believe they are using a wide variety of browser runtimes
Gururaja: I think both are important
Paul: security and performance is an issue
Patrick: with both VISS and RSI
there was choice to start with protocol
... we can use these without changing the browser engine
... if we are building a browser extension, there is no reason
to use a web socket
Magnus: does it matter if there
are competing JS libraries?
... if someone wants to implement their own library with a
different approach, that is fine
Paul: it doesn't matter. to an
OEM they may require which libraries they permit on their head
unit
... they scrutinize what is allowed on the vehicle which is why
you see so few apps at present
Caleb: developers are not going to want to work with such a restricted environment, you want to have competing libraries
Ted: a browser extension spec would limit developers' environments, they would need to have a browser on their dev machines (preferably laptops) that have these extensions
Urata: I understand W3C Director is opposed to standardizing a JS library. if we remove that paragraph would it be possible to standardizing?
Ted: yes but we would need more browser vendors
Urata: what would be their recommendation?
Ted: publish VIAS as a Note and
encourage releasing as a library. people will be very excited
to have a library
... having the library available would be very helpful for
adoption in the industry
Junichi: I would like you to ask
you to consider who would write the library?
... this is a bit different than building into a browser
... developers might be using FF, Chromium etc but in case of
VIAS they would need to test against various VISS servers
... OEM will provide library implementations. I think we will
need some standardized document
Ted: if anyone feels strongly that VIAS should continue, then we will need to find another browser vendor since we require multiple implementations for W3C standards process. If anyone has a JS library implementation I encourage them to release it, they can do so on our github repository. Closed source optimized ones that are tuned for a specific browser runtime could be created as well.
Patrick: as an OEM I would not pay extra for such a specialized browser runtime
Paul: it helps to step back and think about why we are doing this in the first place?
