Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebAssembly+WebUSB port of the SANE scanner library

github.com

Post reply on HN
Print view View original

21–27 of 27 posts

Re: WebAssembly+WebUSB port of the SANE scanner library

#21

Post by askvictor »

incrudible wrote: post #20
askvictor wrote: post #16

Earlier quoted context omitted.

If only there were some kind of language that could compile to a code that could be run on any operating system that could be used for this sort of thing. Oh wait, it's Java and it's been around for 25 years. But quite restricted in it's interaction with the OS, for good reason. As is WASM, for good reason as well. If printer drivers in Java didn't become a thing, I doubt that WASM printer drivers will. Though I can'…

WASM is not a language though, the equivalent here would be a JVM, but that enforces all sorts of Java specific constraints that you do not want in a driver. The short answer to your question is: No.

Yeah, I get that WASM is like JVM (or even more accurately, java bytecode), but doesn't WASM have as many constraints on it?

Can you elaborate on your answer? Linux printer drivers seem to be entirely in userspace, so why do Windows drivers cause so much grief?

Re: WebAssembly+WebUSB port of the SANE scanner library

#23

Post by PaulDavisThe1st »

jmillikin wrote: post #15
PaulDavisThe1st wrote: post #13

Earlier quoted context omitted.

So you feel that e.g. Epson, who could not be bothered to rebuild their existing C-ish driver against a newer version of libc, will instead port it to WASM because ... when they already have working drivers for macOS and Windows that they currently maintain .... I'm lost.

If the standard for Linux scanner drivers was WASM, then companies who publish Linux drivers (such as Epson) would receive perfect forward compatibility for free. If WASM driver support were to be included in Windows and/or macOS, similar to how macOS and Linux share CUPS, then Linux support would be more widespread because the vendor's driver could be reused as-is. I think the thought process behind "supporting one…

> I think the thought process behind "supporting one unified platform-independent bytecode would be easier than compiling a .so that works with all GNU libc versions" is straightforward and self-evident. Do you disagree?

1. it doesn't really matter what I think

2. Compiling a .so that works with all glibc versions is almost certainly an order of magnitude easier than providing a unified wasm implementation that works on (at least) 3 platforms.

Re: WebAssembly+WebUSB port of the SANE scanner library

#24

Post by Brian_K_White »

PaulDavisThe1st wrote: post #14
Brian_K_White wrote: post #11

Earlier quoted context omitted.

I don't see any reason why wasm can't just become another native format. wasm spec is fully defined and public, and we even already have source for browsers. What prevents developing a wrapper or shim that runs any wasm as if it were any other native executable? You might be legally prevented from redistributing the wasm, so maybe you can't bundle it right into a .deb or.rpm, but it's trivial in that case to just dow…

It's typically called a VM. Go up and read about Java, which was fundamentally premised on precisely the same idea, and then see if you can come with some clear reasons why wasm should/will be more successful.

I don't think java has much equivalence or bearing here.

Re: WebAssembly+WebUSB port of the SANE scanner library

#25

Post by PaulDavisThe1st »

Brian_K_White wrote: post #24
PaulDavisThe1st wrote: post #14

Earlier quoted context omitted.

It's typically called a VM. Go up and read about Java, which was fundamentally premised on precisely the same idea, and then see if you can come with some clear reasons why wasm should/will be more successful.

I don't think java has much equivalence or bearing here.

It is a VM like wasm. It runs on every platform. It offers the seduction of "write once, run anywhere" (literally, in the Java marketing, and now increasingly, in discussions about wasm. The more wasm expands its capabilities due to browser extensions the more and more it looks like Java as a platform.

Re: WebAssembly+WebUSB port of the SANE scanner library

#26

Post by franga2000 »

jmillikin wrote: post #4

IMO one of the biggest opportunities for WASM is printer and scanner drivers. These things have historically been distributed as native code, so the usability of the hardware on various OSes and architectures is spotty[0]. WASM is close enough to a native binary (fast, not source[1]) to be accepted by hardware vendors, but is inherently architecture-independent and in principle could be built to an OS-indendent API.…

The problem with printers specifically is that drivers are much more than just a hardware communication layer. Drivers on Windows create the "printing options" UI, which is where most of the interesting functionality is accessed from. Such a common driver interface would have to define a cross-platform UI layer or at least a very advanced configuration API that the print service would render.

Re: WebAssembly+WebUSB port of the SANE scanner library

#27

Post by Brian_K_White »

PaulDavisThe1st wrote: post #25
Brian_K_White wrote: post #24

Earlier quoted context omitted.

I don't think java has much equivalence or bearing here.

It is a VM like wasm. It runs on every platform. It offers the seduction of "write once, run anywhere" (literally, in the Java marketing, and now increasingly, in discussions about wasm. The more wasm expands its capabilities due to browser extensions the more and more it looks like Java as a platform.

neither java code nor binaries are very portable, despite the original marketing. wasm is essentially a binary format. You can certainly make a non-portable wasm just the same way you can make a non-portable elf binary. But you don't have to. You can make a wasm that is even more portable than any elf binary since it's independent of any platform. java byte code may have been theoretically able to do the same, but the jvm ended up being too varied and there is no universal jvm environment the way there is a universal wasm environment. Browser extensions don't remove or modify the base, only add.

java isn't relevant, not because it couldn't be in theory, but because in reality, it's just not. Browsers never baked it in, it never became an open standard, etc, it's essentially no better than every other interpreted or compiled language. We could have a universal standard that's essentially bash, but we don't. We have bash, but it will never be a universal format the way wasm already is. Being baked into everyone's browser makes all the difference. When you want to publish a picture, tiff is a very versatile container and is better than most other formats, but the format you will actually use will be png or jpg etc, because even though many tiff viewers are available, they aren't built in to all browsers. It doesn't matter that tiff already existed and could do the same job. java is tiff.

Post reply on HN