swiftwasm/WebAPIKit

Source of specs?

Closed this issue · 6 comments

j-f1 commented

@MaxDesiatov

With Tokamak you'll have to use the Fetch API, and there are no SwiftWasm bindings for it yet, as far as I'm aware. I guess we will have some in the near future as a part of the DOMKit library, but my understanding is that it's not there yet, and is not a part of WebIDL declarations included there, maybe @j-f1 could clarify? Also, bear in mind that fetch returns a Promise object, and the API for it is still being developed in swiftwasm/JavaScriptKit#62. Closure-based APIs in SwiftWasm are not very trivial to work with, as you have to be aware of the lifetime of your closure instances and manually release them. This is an inherent problem caused by the differences in how JavaScript (garbage collection) and Swift (reference counting) allocate memory for closures and their context.

@j-f1

Indeed — fetch is a separate spec that would have to be integrated. I’m not sure how the original maintainers got the .webidl files out of the specs, and I would like to follow the same process for fetch.

@MaxDesiatov

Yes, it would be great to know where the WebIDL specs come from, as I'd like many more APIs covered eventually, IndexedDB, WebGL (WebIDL for this one is maintained together with the human readable text spec apparently), Web Animations obviously, and whatever comes next that users would be interested in.

I’m guessing they were extracted from the .bs files by looking for the <pre class=idl> blocks. @Unkaputtbar @PSchmiedmayer do you have any more information on how this was done?

mjburghard commented

I looked up the WebIDL specs through the MDN web docs. The specification sections of a Web API usually links to the official specification. Then I just copied the specification into a .webidl file, .e.g. https://developer.mozilla.org/en-US/docs/Web/API/EventTarget and https://dom.spec.whatwg.org/#interface-eventtarget.
Browsers also may have WebIDL files in their repositories.

  • 👍2
  • ❤️1
j-f1 commented

OK great, so there wasn’t an automated tool I was missing. I’ll see if I can code one up!

j-f1 commented

alright, I’ve got things mostly working now, although I need to find a way to parse the html spec, where several important things are defined, but is formatted with HTML tags inside the code.

Error: The following types are undefined:
	- AbstractWorker
	- CacheQueryOptions
	- ClientQueryOptions
	- ClientType
	- EventHandler
	- ExtendableEventInit
	- ExtendableMessageEventInit
	- FetchEventInit
	- HTMLFormElement
	- HTMLSlotElement
	- MessagePort
	- PostMessageOptions
	- RegistrationOptions
	- VisibilityState
	- WorkerGlobalScope
	- XMLDocument
MaxDesiatov commented

I guess this can be closed as outdated, right?

j-f1 commented

Yep, so glad that webidl2 exists!

  • 🎉1