apignotti

I see the caching argument only partially. It applies to any ranged request, non just compressed ones, and there are plenty of ways for origin servers to describe what and how to cache content. The origin may explicitly only allow caching when the access patterns are expected to likely repeat.

A point of great pain for me in the use of HTTP range headers is that they are absolutely incompatible with HTTP compression.

This boils down to an ambiguity found in the early days of HTTP: when you ask for a byte range with compression enabled, are you referring to a range in the uncompressed or compressed stream?

The only reasonable answer, in my opinion: a range of bytes in the uncompressed version, which is then compressed on-the-fly to save bandwidth.

I suspect the controversial point was that originally HTTP gzip encoding was used via pre-compression of the static files. On-the-fly encoding was probably too computationally expensive at the time.

Anyway, the result of this choice done decades ago is currently preventing effective use of the ranged HTTP requests. As an example, it is fairly likely that chunks from the SQLite database can be significantly compressed, but both HTTP servers and CDN refuse to compress "206 Partial Content" replies.

Interestingly, another use case of HTTP byte ranges is video streaming, which is not affected by this problem since video is _already_ compressed and there is no redundancy to remove anymore.

I would argue that the speedup is critical for being practically useful.

In terms of use cases: education, testing, documentation, distribution of applications, safe execution of legacy applications... and there are surely many others

Direct link to the live version: https://webvm.io

Support/Discussion: https://discord.leaningtech.com

Lead dev of CheerpX/WebVM here. Happy to answer questions.

Wasm cannot indeed do much beside manipulating it's own memory and pure computation. Anything interesting happens via "imports", which are arbitrary functions implemented in JavaScript.

The networking capabilities are implemented via a JS API (itself, compiled from Go to WebAssembly/JavaScript). This Go library connects to Tailscale DERPs via WebSockets to provide network access to the Tailscale network of each user. The broader internet can then be also accessed if an exit node is configured.

Hi, lead developer of CheerpX here. The main difference is about the level of performance we can reach thanks to our sophisticated JIT engine. Feel free to try running a payload yourself in v86 vs WebVM to see the difference.

My latest talk on the topic is available here: https://www.youtube.com/watch?v=rI7opIKW_z4

Direct link to demo: https://webvm.io

Yours is a fair question. I think that, right now, adoption of WebAssembly is quite limited. On the other hand (here at LeanigTech) we are extremely bullish about its potential.

We believe that this technology would be adopted more with better tooling. Our main contribution to this space is Cheerp: A C++-to-WebAssembly _and_ JavaScript compiler (https://github.com/leaningtech/cheerp-meta/). It is designed to seamlessly take advantage of Wasm without sacrificing easy access to Web APIs, all from within C++ with no need of post-processing and glue code.

We know for a fact that amazing products can be build with Cheerp, because we have done it ourselves.

CheerpX is a x86 virtual machine running in the browser, fully written in C++ and compiled with Cheerp. It includes a JIT-compiler that is able to analyze x86 binary code and emit new WebAssembly modules on the fly.

Our most impressive demo yet (WebVM) is available here: https://webvm.io/

We emulate a Linux system indeed

Shameless promotion: a technology like CheerpX has many more uses

Our latest demo (PythonFiddle) is discussed here: https://leaningtech.com/pythonfiddle-fully-private-client-si...

Direct link: https://pythonfiddle.leaningtech.com

From the point of view of Adobe, Flash is a legacy technology. Simply put, there is not enough business to be made with it at Adobe's scale.

It is safe to assume that the Flash team has either left the company or moved to other roles in the meantime. The Flash codebase is gigantic, evolved over decades and probably includes IP with non-obvious licensing restriction (RTMP is an example that pops to mind). Porting to Wasm such a big codebase would require assembling a new team and figuring out some legal aspects. Both these things are expensive.

At the same time, FOSS efforts to replace Flash can at best achieve partial support for SWF content in the wild. The API surface is just too massive and poorly documented. I speak from personal experience here, having founded the Lightspark project when I was younger and with a lot of time on my hands.

Our opinion (at LeaningTech) is that Wasm can solve the Flash preservation problem by virtualizing the original, unmodified Flash x86 plugin. We wrote at length about our approach here: https://medium.com/p/eb6838b7e36f

The resulting product (CheerpX for Flash, https://leaningtech.com/cheerpx-for-flash/) is available to companies that needs to use Flash (and particularly, Flex) business applications.

Since the SWF effectively runs using the original Flash plugin the accuracy is optimal. On the hand, licensing the plugin itself is required, which means that the solution is not viable for end-users. As much as we'd like this to be different, it's unfortunately outside of our control.

Full disclosure: I am founder and CTO of Leaning Technologies, and lead developer of CheerpX

Hope this helps: https://teeworlds.leaningtech.com/

This is possible, and trivial, when self-recursing: A -> A

If you have an A -> B, or A -> [indirect] call, that is not the case.

Tail-calls is fundamentally something that the compiler _cannot_ solve. Trust me, if there was a way we would have avoided ourselves all this work.

The issue is that to avoid stack blow-up you need the engine to recycle stack frames. You might argue that this could happen implicitly in the VM, with all the calls in tail position being automatically converted to tail-calls. The problem with this is that in WebAssembly (and JavaScript) the call stack is observable via the .stack property of thrown exceptions.

Since an implicit conversion would be observable engines cannot simply optimize the problem away, and that is the reason why new opcodes (return_call/return_call_indirect) are actually required at the WASM level.

For the specific case of direct calls (return_call opcode) the compiler could solve the problem by inlining, with some luck. But for the case of return_call_indirect there is no other possible solution.

> support for network connections

I wish daily for that as well, but stay tuned: we _might_ have found a half-satisfactory solution for that ;-)

I am unsure, but I can make a guess. The first release of Wasm has been always considered a Minimum Viable Product, which a strong emphasis on Minimum. Pretty much only features already part of the legacy asm.js "standard" made the cut.

The fact that WebKit had some level of support for tail calls on the JS side is exactly the reason we choose it as the right platform to invest in.

https://webvm.io is our public demo of CheerpX, an x86 virtualization technology made with WebAssembly.

At Leaning Technologies we have been using WebAssembly pretty much from day 1 as part of our C++ and Java compilers. CheerpX is our latest product, and we think it really pushes the boundaries of what is possible in the modern browser.

Direct link to our interactive demo of CheerpX: https://webvm.io/

Hi, CTO of LeaningTech and lead dev of WebVM here. Thanks for mentioning our tech, which we believe to be the most advanced currently existing.

I am happy to answer questions.

There is a very big difference: ActiveX was native code that was literally running on your system with full access to system calls.

CheerpX is a Virtual Machine environment, it JIT compiles Wasm code from x86 binaries and it is fully sandboxed by the browser. It _cannot_ access your system even if it tried.

> This company has an x86-to-WASM compiler that lets you execute arbitrary binaries in the browser.

Direct link to our latest demo in case anybody would like to see this tech in action: https://webvm.io

The actual host hardware does not matter, neither in terms of support or performance, theoretically. We currently optimize the codegen for Chrome/V8 on x86.

That's an unimplemented instruction. If I have to make a guess, one the trigonometric funcs you are calling. Feel free to report a bug if you'd like.

Well, nodejs uses V8 and it's installed

It depends on the definition of "functioning".

If you'd like to access a server from another tab / iframe of the same browser, that's almost possible already, just some UX work would be required.

If you'd like users of the same page (or a separate specialized page) to connect, that could be possible with WebRTC.

If you'd like arbitrary hosts to connect, that would require a server side proxy, there is no client-side only solution that I can see,

Well, User Mode Linux would still require an underlying Linux ABI, for example mmap to implement pagination. With sufficient work it might be possible to actually run UM Linux _on top_ of CheerpX / WebVM.

Implementing the Linux ABI ourselves gives us the opportunity of a tighter integration with the Web platform anyway.

That's correct.

Thanks, appreciated.

By the way, it's spelled "Cheerp", with a lowercase p :-)

HTTP request could be intercepted, but due to CORS they would most likely not succeed. I have not studied the WebRTC protocol in detail but it might be possible.

Not in the current implementation, but absolutely possible with WebRTC. We have done something equivalent some time ago: https://medium.com/p/29fbbc62c5ca