Re: [w3ctag/design-reviews] Realms API ECMAScript Proposal (#542)

Also, I've had a use-case for Realms for several years now and I'm not sure the current approach still allows me to do what I want to do...

A while back I designed an extension to [Home Documents for HTTP APIs](https://datatracker.ietf.org/doc/draft-nottingham-json-home/) that adds JS function bindings to HTTP API endpoints. The idea is that a browser can load the document describing the HTTP API, auto-generate a class that implements the API as JS methods, and return an instance of that class ( a 'remote object'). The consumer of the API just sees a regular JS object, whose implementation comes from the server (each method returns a promise that does a Fetch under the hood as defined by the Home Document). The Home Document can also carry internal state exposed as properties on the remote object (in addition to private state), and that state can be manipulated by the HTTP API by returning a JSON-Patch. I also built a polyfill that implements this (this repo is a bit out of date, I've been using a more recent version in production code, but it gets the idea across): https://github.com/plinss/remote-web-objects (the live-demo is no longer online)

One feature I wanted to add is to allow the Home Document to also carry raw JS code that implements synchronous methods run entirely client side. That code should be restricted to interact with the remote object and nothing else. I was planning on being able to create a Realm that's scoped to the remote object. Doing this would require the ability to share that object's internal state between the code running in the realm and the Realm's parent. It's not clear if this kind of thing can still be built with the current proposal. 


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/542#issuecomment-840860450