[bumped to plenary - possibly we can close]

Ken: we gave feedback, they filed issues.

Sangwhan: issues with API design... I provided some feedback. I suggested an alternative design to this. Factory that creates another factory... factory for oepration. Model builder give me an add operation.. model builder give me an xyz operation...

Dan: is the way they are building this coherant? The way the community builds these kinds of things?

Sangwhan: no

Dan: why are they building it this way?

Sangwhan: mapping native optimisation APIs straight to the web. Inspiration from Android API. Not justifiable. This JS example. They're saying it's for frameworks so it's fine.

Dan: this is an area we can provide feedback not specific to the neural network use case. Does design principles say don't do that? Low level vs high level. If you're designing this for the web you really need to think about how web developers are going to use it, not simply rely on frameworks. Parts of the web people dislike working with are the parts that have been designed in this way.

Ken: if you can make the api nice even if it's low level... might be use case for this in the future

Sangwhan: a couple of things they ignored in the principles, constructors. Everything is a factory pattern, but you should bind when you compile the graph and transfer it to the coprocessor, that's more common in actual frameorks. The only framework that does that they're doing now is tensorflow. types code in jitsi chat

model = nn.Sequential(
        nn.Conv2d(in_channels=1, out_channels=6, kernel_size=5, stride=1),
        nn.Tanh(),
        nn.AvgPool2d(kernel_size=2),
        nn.Conv2d(in_channels=6, out_channels=16, kernel_size=5, stride=1),
        nn.Tanh(),
        nn.AvgPool2d(kernel_size=2),
        nn.Conv2d(in_channels=16, out_channels=120, kernel_size=5, stride=1),
        nn.Tanh(),
        nn.Flatten(1),
        nn.Linear(in_features=120, out_features=84),
        nn.Tanh(),
        nn.Linear(in_features=84, out_features=10),
        nn.Softmax()
    )
model = model.to('cuda0')


with tf.device('cuda0') as d:
    blah blah blah

Dan: I opened up a design principles issue to capture this.

Ken: sounds like you have good arguments about why they should redesign this

Sangwhan: I do.

Ken: I think they have implemented and have polyfills.

Dan: what's the advantage of having this api vs someting that sits in webassembly

Ken: they can use hardware

Dan: doesn't webGPU give you..

Ken: some of it, but hardware made for machine learning is always better

Sangwhan: in mobile phones you have a neural coprocessor which is not a GPU. A multiplication machine.

Ken: these are becoming more and more common.

Sangwhan: I don't think gup based computation is going to be a very common thing to do for this.

Ken: the approach is the same as WebGL. Mapping the OpenGL API to the web, and it's a terrible API for JS developers, which is why everyone is relying on frameworks [e.g. 3js] because it's so difficult to use. For WebGPU they're actually trying to make an API you can use as a developer directly, even though you might want to use a framework. WebGL feels like a C API, very foreign to web developers.

Sangwhan: I will join one of their calls

Dan: can we summarize into or issue?

Sangwhan: wanted to bring up priority of constituencies, but doesn't capture that APIs should be useable by average devs. When we bring that up there are plenty of counter-examples... extensible web manifesto says apis should be low level

Dan: We have more nuanced language in there now

Ken: something low level doesn't have to be bad

Dan: milestone to 29 March

Ken: they filed issues for all of the issues - they did that on a call in the wg and they haven't finished yet. Someone from MS commented. Seems that they are listening to our feedback. Sangwhan seemed happy with the asnwer. This is an early review and we've given feedback - to which they have been receptive. They are listening.

Dan: looking at PR that resolves some issues...

Ken: unless we have major concern... i think they're handling that in the WG itself. Of course there's concern about how the field of machien learning is evolving, is it going to change, but Intel is positive, Microsoft is also positive, they believe it's the right path forward. Google had some ideas of doing something smaller, but these are the discussions in the WG. It's not shipping.

Dan: We might want to close this at the plenary. We need Sangwhan.

[sangwhan joins]

Sangwhan: they haven't addressed the ergonomics of the API. It's not developer friendly. Their reasoning is that this makes it easier for them to bind it to hardware. But I'm not sure if that's..

Dan: the point of an API is to make it easier for the developer

Ken: how is that different from webgl and webgpu

Sangwhan: I'm not suggesting those are good, a nn is more of an application API rather than a hardware API. That's the bit that makes me uncomfortable. Their rationale is that this is for framework developers

Ken: that's the same with webgl

Dan: people use things like iframe and libraries

Sangwhan: that's the main concern I have. We might want to take a position on where we draw the line of these are APIs that are for framework developers and these are APIs that are supposed to be used as-is. We shouldn't have that many that are designed only for framework developers. But there's also the extensible web manifesto that suggests everything should be low level

Dan: we have more measured wording in design principles about that now.. don't we? Are we still talking about low level vs high level?

Sangwhan: it's a standing issue. I don't have strong opinions that the web should be this or that. Feels like we should draw a line on where we say this is best as a low level API and this is best as a high level API

Dan: in the issues .. they haven't addressed all of our issues

Sangwhan: other issues I raised are minor compared to this ergonomics issue. Number 8.

Dan: they think we're asking them about the ergonomics of the examples, you responded that it's the API itself.

Sangwhan: the API is incredibly loquacious. You have to do a lot of boilerplate. Rationale is you don't have to invent new types and can work with hardware, but it's really not nice to use. That's my main concern. It feels like C code. They haven't addressed that.

Dan: we need to be stronger then on our response. We need to say in our issue we appreciate they're being responsive to the list of issues. The main thing we're still concerned about is the developer ergonomics and pointing to that example. That might sound like we're asking them to reinvent the whole thing. We could suggest that there need to be better developer ergonomics, ways to use this API that don't require that amount of syntax

Sangwhan: I've suggested that on their issue and the response I got was it's fine because of framework developers

Dan: my suggestion is to say that's not okay. It is worth nothing that both WebGL and WebGPU are good examples of notoriously difficult to use APIs that nobody uses and developers don't like working with because they're design in this way. That ties people to dominant frameworks. Which creates a different set of problems.

Sangwhan: even the native people gave up on WebGL and WebGPU, that's why unity and realty are a thing.

Dan: it's example of a bad practice.

Sangwhan: I don't want to block their work or have them reinvent the API.

Dan: they should have an optional way to interact with the API that's built in and doesn't require you to use a framework on top of it.

Sangwhan: I'm surprised that the person who wrote the example code didn't feel the API is not user friendly. I will reply on their issue that is separate. Do we have consensus that we want developer friendly APIs over hardware friendly APIs?

Dan: this is a design principles issue 117 which is still open. We need to discuss it in that context. Feels like we do have that consensus but we haven't documented it. Lea is working on a PR, there's one open (291) which among other things talks about how you shouldn't exclusively develop low level APIs, design high level in terms of building blocks over low level... ensure continunity and ease of use..

Sangwhan: if we have group consensus I can say yes we don't want lots of boilerplate in the APIs

Dan: I feel like we do have that consensus. We can further discuss in the plenary.

Sangwhan: one part of the API design choice I do understand because javascript doesn't have operator overloading. Makes it hard to make this kind of API.

Ken: wasn't there some work on that?

Sangwhan: still stage 1

Sangwhan: raised issues, not satisfied, don't know how to deal with this

Ken: make sense to summarise in the issue?

Sangwhan: API is not great

Ken: support from MS and google?

Sangwhan: MS and intel pushing it. Parts I did not like... see issue 89, 139 is my main gripe

Ken: can live with low level API, but want to make sure it's futureproof

Sangwhan: also annoyed about 138. Need background knowledge. Bits that are extremely tied to specific hardware accelerated NN features. Gated Recurrant Unit.. used to remove background noise in video conferencing. LSTN is more common but not supported.. hardware acceleration for GRU, found it strange

Ken: some of the use cases driving this.....

Sangwhan: weird restrictions for GRU, weird inconsistency in the API

Ken: sounds like a good comment

Sangwhan: I've been saying this, they say it's because of hardware.

Ken: how does the hardware look in five years?

Sanghwan: Exactly.

Ken: what hardware? Intel, Apple? Might differ.

Sangwhan: I suggested.. if there's hardware that doesn't support it I suggested it should throw, they said no.. suggested canPlay type mechanism to probe if you can do it... they said no. ... Invite these people to a call? Issues are difficult because you need a lot of background to get started. ... Push to plenary.. see if chairs can help.

Ken: sounds like this has support from Google and Microsoft...

Dan: last comment from anssi sums it up well. They have made a numnber of changes based on our feedback. It's all tracked in their repo. They have transitioned from CG to WG in the mean time.

Ken: leaves comment on readability of code examples

Dan: leaves comment asking about multistakeholder support

Sangwhan: I [still] have some concerns regarding the design of that API (in particular, the low level nature of it) [but] feel free to close