Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Client-side API #353
Here’s the current, rather hacky implementation of the client-side API so we can start discussing the implementation approach.
The basic approach is to define an API and expose it to
Here’s the code for an example batch processing app.
We need to decide if the API is solely for computation, or if it's a UI driver. From this PR it seems like the latter, and I think that's the right direction. That works for things like a share target API, it works for creating a glitch that opens a particular image with particular settings (once we expand the API to include settings). But that means the API needs to cope with user interactions that might happen during its driving, so calls should
I don't have a strong opinion if this is done with events, or promises stored on the instance.
Some things to think about:
If the user changes some compression settings on the left, then the API changes settings on the right, should the API returned promise wait on both sides to finish compressing, or just the right?
If this is a UI driver, should we separate the setting of things from the completion of things? Eg, if I
What's our backwards compatibility story here? Should the API involve some sort of version check? We could change our major version when the API breaks compatibility.
The more I think about it, the more I agree it’s what we should aim for.
I’ll see if I can add a got way to add that.
I don’t think it should.
It’s mostly how it works right now, but I think you are right that more explicit events (?) for intermediate steps would be nice.
It’s probably a good call to add a the major version to the handshake and just abort on mismatch.
I'm leaning towards promises being better, but I'm not awfully sure. After driving the UI, you could get a promise for "image decoded" (which is when you could get width/height & format if we offered it), and a promise for the complete encoding of a particular side.
Edit: When I say "get a promise", I mean it'd be an additional call to get that promise. The methods themselves would resolve once the state is set.
Error I think.
Does this create a privacy problem?
It seems like we need to limit usage of this API to cases where the source of control is obvious, eg iframes, as the URL bar will display