Library or browser API

[dontcallmedom]

VIAS claims to define an API that can be provided as a JavaScript library or implemented in a Web rendering engine.

The best way to provide an API for a JavaScript library is to build such a library - is there a reference implementation of that library? Also, in general, WebIDL brings a lot more constraints on interfaces and objects than a simple IDL, so making a really conformant implementation of the API in JavaScript would be challenging, and probably for no good reason.

Using WebIDL for a Web rendering engine API is naturally the right thing to do - but that seems a bit heavy-handed for something which is basically a wrapper to a Web Sockets (which seems much better served by a library indeed).

It's not clear to me there is value in standardizing a specific wrapper to the Web Sockets protocol: providing the wrapper as a library would seem more efficient. (if it's good, it will gain wide adoption; if it's not, it won't - as would happen to a standardized wrapper)

[peterMelco]

I think that your point " if it's good, it will gain wide adoption; if it's not, it won't - as would happen to a standardized wrapper " makes a lot of sense. Would anyone really consider putting this in web engine ? Maybe @aShinjiroUrata would like to comment ? as he is representing web browsers vendors in the group.

[aShinjiroUrata]

Thanks for the comment, Dominique-san, Peter-san.

The best way to provide an API for a JavaScript library is to build such a library - is there a reference implementation of that library?

I'm creating a simple prototype (50% coverage for now) which is basically for the pupose of writing workable test cases.

1. One use case of VIAS is a wrapper library for VISS and from this point of view VIAS may not be very important.
   However, to use VISS directly, management of 'rquestId', 'suscriptionId' is kind of boring and troublesome task and certain amount of API users might create wrapper with their original API style and write very simlar implementation by themselves.
   If so, defining easy to use API (=VIAS) and provide wrapper library would save a lot of work of API uses and helpful.

2. Another use case of VIAS is not a wrapper of VISS but implemented in browsers as native API (or implementation in other WebRuntime such as Node.js, etc.)
   In WG discussion, there is a opinioon that this type of implementation is also included in the scope of implementor's freedom.
   From this view point, what is important is VIAS and VISS is just a implementation detail [1]important spec is VIAS and on the other hand, VISS is rather an implementation detail which is something API users don't have to care.
   In the implementation of VIAS, implementers can chose communication method such as IPC [2]such as HTTP, MQTT or IPC etc. and message format as they like since those are implementation details.

When a web application developer write an application using VIAS API, the application would be able to run on both 1. and 2. implementation. Therefore defining VIAS has some meaning.

Excuse me that my expanation is not very good but in my understanding, this is the reasoning of VIAS in WG discussion.

By the way,

WebIDL brings a lot more constraints on interfaces

what you mean by this sentence is something about types? or any other thing?

2017/9/25 urata revised:
[1] revised since sentence was not clear
[2] revised since, in WG discussion, HTTP, MQTT (CoAP also) were raised as alternative communication method as well.

[dontcallmedom]

Uarata-San (@aShinjiroUrata) - I don't disagree that a wrapper around the WebSockets protocol would be useful, but I don't think it needs to be standardized (vs released as an open source library).

Regarding web runtime engine provided implementations of the API, I think the only piece that would be needed to be made available directly by the engine is the connection to the VISS server (e.g. if it's not directly reachable otherwise); again, the rest of the wrapper can and should be provided as a library, which provides much greater flexibility than a standardized API.

I can see that this approach breaks down if the communication with the vehicle is not done over websockets - but I think it is setting the bar pretty high to expect that any other IPC mechanism will be wrappable in the same API as one defined to wrap a WebSocket protocol.

Regarding WebIDL, as it is a language defined for browser-implemented APIs, applying it to JavaScript-implemented ones is awkward - for instance, interface is meant to define only platform objects when a JavaScript library defines user objects - this has a number of implications on how these objects behave.

[aShinjiroUrata]

@dontcallmedom -san, excuse me for delayed response.

Uarata-San (@aShinjiroUrata) - I don't disagree that a wrapper around the WebSockets protocol would be useful, but I don't think it needs to be standardized (vs released as an open source library).

I understand this as an opinion.
On the other hand, I still think that standardization has meaning that

• if provided as an open source library, it is just an implementation example and
  we are not sure that it may be used commonly.
  By providing easy-to-use API which is commonly used, many developers can write applications
  using the same API and it would be compatiblly run on various vehicles.
  From this aspect, I think VIAS standardization has some meaning.
• To think 2.(= VIAS usage not as wrapper of VISS) usage of my previous message,
  (although @dontcallmedom -san is negative on this usage)
  even implementation is different (such as wrapper of VISS or native implementation in browser)
  API user can use a same set of API.

As this is rather a big topic, if other members have opinion, I'd like to listen to it.
(or I'd like to discuss in F2F at TPAC.)

I can see that this approach breaks down if the communication with the vehicle is not done over websockets - but I think it is setting the bar pretty high to expect that any other IPC mechanism will be wrappable in the same API as one defined to wrap a WebSocket protocol.

In WG discussion, we thought that VIAS API would be realizable over
almost any underlying communication (IPC, HTTP, MQTT etc) because VIAS
is a set of simple APIs such as get(), set(), subscribe() and if vehicle information could be
obtained from vehicle data source (via any communication), API implementation would be
basically simply achievalbe.
Actually I'd like to know the reason why you think this "approch breaks down if not over websocket".
(Excuse me but I added HTTP and MQTT as communication example since it also appeared
in our discussion)

Regarding WebIDL, as it is a language defined for browser-implemented APIs, applying it to JavaScript-implemented ones is awkward - for instance, interface is meant to define only platform objects when a JavaScript library defines user objects - this has a number of implications on how these objects behave.

I understand the point.
In our discussion, we did not think this point is a big problem since some of W3C's API
could be implemented as JavaScipt polyfill.
We though that API implemented as native and implemented as polyfill are virtually
not different from API user's point of view.
Do you think this usage of WebIDL is not acceptable?

[aShinjiroUrata]

Seems there is no more comment, close this.
Please reopen if someone want to continue.

[tguild]

Lack of recent comment is not criteria for closure. This warrants further discussion and consensus before closing.

[aShinjiroUrata]

Hi. Ok, I understand.
I closed since I thought I already answered the question.
My thought is already written in above and I have no more input on this issue.

[tguild]

VIAS is not presently continuing on REC track and was published as a Note.