Ještě koukám na to WebUSB. Pokud připojím USB zařízení bez další konfigurace OS, na všechny jeho standardní funkce se napojí systémové ovladače a předpokládám, že se na ně libusb/WebUSB nedostane. To by vyžadovalo blacklist zařízení v OS, což už je pro uživatele veliká komplikace. Možná proto Chrome v dokumentaci k extenzi WebUSB píše "The WebUSB API exposes non-standard Universal Serial Bus (USB) compatible devices to the web".
WebHID je zatím v plenkách https://developer.mozilla.org/en-US/docs/Web/API/WebHID_API#browser_compatibility . U přístupu na HID přes browser píše Mozilla https://developer.mozilla.org/en-US/docs/Web/API/HID "This feature is available only in secure contexts (HTTPS)" - jak se vlastně dostane lokální SPA do secure contextu?
Jo, tohle mi přišlo jako vcelku dobrý nápad. Speciálně právě pro lokální administraci různých zařízení a gadgetů.
Není to zdaleka tak nové, registruju to minimálně 8 let. Největší praktický problém je v tom, že je to v podstatě aktivita od Google. Takže jejich produkty to sice podporují už hodně dlouho, ale v podstatě nikdo jiný.
Na Andoridu, ChromeOS to chodí v pohodě, do PC, macOSu nebo Linuxu si člověk doinstaluje jakýkoliv Chromium based prohlížeč, pokud už ho tam rovnou nemá. Ale není cesta, jak to rozchodit na iOSu (což je pořád tak čtvrtina uživatelů na mobilních patformách).
Ten myšlený use case mi přišel tak, že místo toho, aby výrobce gadgetu dělal nativní aplikaci pro x různých platforem, tak udělá webovou administrační aplikaci s JS na svém webu, aktualizuje jí podle potřeby (bez koleček schvalování, publikování na storech) a když si uživatel ten web otevře, a povolí přístup, tak může ovládat gadget.
Takže není to off-line, ale to myslím, nebyl ten hlavní point. Pokud je to nějaký otevřený projekt, může to plácnout třeba na GitHub Pages - github.io a propojit do hlavního projektu, kde jsou pak zdrojáky. O HTTPS se pak nemusí starat.
HID zařízení (BaseClass - 03h) s nějakou šikovně vybranou podřídou, aby se to v systému nechytalo jako standardní vstupní zařízení (tzn. dostupné pro custom ovladač, nebo třeba WebHID), se vcelku běžně používají. Jak pro nějaká vstupní ovládací zařízení (pady, joysticky, tlačítkové panely), tak i třeba ovládání USB zvukovek (pokud to nejsou zrovna ovládací prvky, co chce výrobce namapovat do standardní audio třídy). Oproti těm některým ostatním základním třídám, které rovnou vyžadují samostatný ovladač, to má výhodu v tom, že to nikde v systému (Win) nevisí jako neznámé zařízení a jsou už definované základní parametry inicializace, komunikace co používá interrupt transfery s nízkou latencí.
Zas samozřejmě pokud by bylo potřeba přenášet nějaké kýble dat pomocí bulk nebo iso transferů, tak to není úplně nejvhodnější. Proto tam taky často bývá třeba další endpoint vyloženě s DFU třídou pro update firmware.
Jinak, neříkám, že je to pro konkrétní použití (co neznám) úplně nejvhodnější, jestli je tam nějaký silnější SBC, co už má Ethernet, tak se vyloženě nabízí to využít. Protože přístup z více zařízení, i přes WiFi atd. I když tam samozřejmě můžou přijít zmíněné komplikace s certifikáty atp.
Jen jsem chtěl zmínit na co ta USB JS API asi byla původě míněná.
36 Odpovědí
8301 Zhlédnutí