Браузер как гипервизор

[ermouth]

Я вчера, уже когда засыпАл, пребывая под впечатление от Win95 на JS, размышлял, чего же не хватает, чтобы сделать из браузера условно-полноценную платформу для виртуализации. То-есть, сделать из браузера гипервизор.

В диктофон записалось “локалсторидж и юдипи”, после этого я уснул. Расшифровываю.

Синхронная файловая система

В браузерном JS есть всего две сущности, которые могут сойти за синхронную запись/чтение на файловую систему, и обе очень ограниченные.

localStorage – единственная локальная браузерная БД, чтение/запись в которую синхронные. Главная проблема – localStorage крошечный, единицы мегабайт.

Есть ещё IndexedDB и уже считающаяся устаревшей (а напрасно) WebSQL – они дают объём до 1/10 диска на домен, но они обе асинхронные.

Synchronous XHR – синхронный ajax-запрос. Это сетевой запрос, а не локальный, стало быть сразу прилагается куча соответствующих проблем. Более того, Mozilla пометила синхронные ajax-запросы как deprecated.

В этой связи я предполагаю, что либо лимит на localStorage будет увеличен, либо появится какой-то новый механизм (либо адаптация имеющегося).

Про “адаптацию имеющегося” я говорю вот почему. В браузерах накоплено существенное количество самых разных технологий, которые могут очень неожиданно сочетаться. Например, btoa(unescape(encodeURIComponent(string))) служит для конвертации в base64 unicode-строк, и лишь единицы самых рафинированных экспертов впервые её увидев скажут вам, как и почему это вообще работает. Хотя все три функции – “системные” для браузера, их сочетание вводит в полный ступор сначала.

UDP

Сейчас в браузере нет никакого способа выполнять UDP-запросы. Я не думаю, что он появится, потому что такая возможность ставит под угрозу безопасность не конечного пользователя, а всей сети. Тем не менее, очевидно существует множество “классических” приложений, которым нужен UDP. Как тут быть, не очень понятно.

В браузере есть некоторое "идейное” подобие, чтоли – называется WebRTC. Эта технология предназначено для веб-версий “настольных” технологий, где UDP задействуется особенно широко. Потоковое видео, VoIP и тп.

Возможно, WebRTC будет как-то адаптирован под более широкового плана нужды.

Итого

Френды, если есть у вас какие-то навскидку соображения про фундаментальные ограничения на идею “браузер как гипервизор” – напишите плиз коммент.

Comments

[morfizm.livejournal.com]

Пока быстрые мысли такие. Браузер фундаментально ограничен, во имя безопасности, чтобы не виртуализировать очень многие девайсы (скажем, сканнер, или блутуз). Соответственно, либо в браузере таки появится эта виртуализация, ЕСТЕСТВЕННО, с целью реализации полноценной виртуальной машины на браузере, либо единственным способом это добыть будет устанавливаемый плагин. Через плагин можно решить вообще всё, сам понимаешь, можно же заинсталлить любой нативный код под админовскими правами, юзер один-единственный раз должен будет "согласиться" :) Но maintain'ить подобный плагин, да ещё и поддерживать разные браузеры, это мегагемор. Тут не обойтись без какого-то стандарта. Чтобы возник стандарт, нужен интерес. Просто "запускать виртуальную машину в браузере" не есть слишком уж интересный, популярный и востребованный юс-кейс. Нужны более насущные юс-кейсы, которые будут движущей силой для создания соотв.инфраструктуры - стардарта и кросс-платформенных фич для виртуализации всего-всего локального говна вроде сканнеров и блутузов. За storage я бы волновался в последнюю очередь, т.к. уже есть куча приложений которые обуславливают потребность в локальном storage. Да, он вырастет, да, его будет легче контролировать, это уже как бы почти очевидно. Всё остальное - х.з. Как насчёт DirectX или OpenGL, например? Доступ к GPU? Как насчёт виртуализации сетевой карты? Ну, короче, фундаментально мы упираемся в набор достаточно востребованных приложений, которые, когда станут актуальны, позволят это всё заимплементить как кроссплатформенный стандарт. Технических ограничений я не вижу вообще.

[morfizm.livejournal.com]

Есть ещё одна вещь... драйвера обычно медленные ИЛИ небезопасные (read: executing random native code that has access to everything). Инфраструктуры для безопасносных и быстрых драйверов девайсов ещё не придумано. Это тоже bottleneck во всём этом деле.

[ermouth.livejournal.com]

Я эту проблему представляю, хотя и несколько с другого ракурса.

У меня на все соображения касательно «медленные» ровно один ответ – «медленный код» например 10-летней давности летает пулей на нынешнем железе даже с несколькими слоями перед CPU и после всех перекомпиляций туда-сюда.

[morfizm.livejournal.com]

Проблема в том, что нет работающего кода 10-летней давности, годящегося для сегодняшних девайсов. Представь себе десятки тысяч моделей всякого говна. Нужен фреймворк, чтобы, ну если не всё это, но хотя бы большинство из "нужного" могло работать с использованием безопасных драйверов. Эти драйвера совсем не обязательно должны работать ВНУТРИ браузера - нет, не в этом дело. Они всего лишь должны быть гарантировано безопасны, чтобы команды, составленные авторами сайтов и передаваемые в драйвера из браузера, не могли добраться ни до чего из недозволенного им.

[morfizm.livejournal.com]

Кстати, на сегодняшний день даже такие простые вещи как клавиатура и мышь виртуализированы весьма уёбищно, и совсем не кросс-платформенно (ну, как бы кросс-платформенно если ты возьмёшь лишь очень ограниченное подмножество нажатий).

[victorgr.livejournal.com]

Подскажите, а почему именно такие требования - синхронные чтение/запись?
Ведь файловая система тоже работает асинхронно, и в лучшем случае она просто сообщает в ответ "окей, записала", в то время как данные еще на пути к магнитным пластинам.

[ermouth.livejournal.com]

Потому что вы эмулируете систему, для которой синхронность может быть важна, то-есть важно сохранять гарантированный порядок исполнения. При этом вы а) в одном потоке, б) не можете остановить ивент луп этого потока никаким способом, кроме как исполняя синхронный код.

Техническим мы, конечно, можем говорить о каком-то синхронном кэше, который сливает по мере накопления всё в асинхронную базу. Но у нас же а) может несколько вкладок быть, б) непонятно как лочить.

[victorgr.livejournal.com]

Фактически ФС именно этим и занимается - эмулирует синхронность поверх асинхронности, даже не всегда с этим справляясь.

Ну и если мы достигнем настоящей синхронности, отзывчивость приложения стремительно упадет - ведь мы действительно будем ожидать, пока битики запишутся на пластинку.

Так что, похоже, что лучше уж научиться жить асинхронно.

[morfizm.livejournal.com]

Ты прав. Было бы вполне достаточно, если бы local storage давал такой же API, как файловая система. В нём таки есть flush как через API, так и автоматически по закрытию файла (реально на диск может и не записаться, но кэш гарантирует синхронность если из соседней вкладки происходит открытие только что закрытого или flush-нутого файла).

Ту же проблему можно решить и другими способами. Например, давать не только file-like API, но и базу данных с сихнронизацией между вкладками. Или давать API для discovery of other sessions and message exchange between them (тогда можно синхронизировать at application level). Но главное, что это должно поддерживаться browser-ом, следовательно, должно войти в стандарт, следовательно, должен быть достаточно большой application demand.

Пока application demand небольшой, и я не вижу особого тренда в эту сторону. Всё ещё идёт мощный обратный тренд - типа в жопу всякие локальные storage'и, давайте всё хранить в cloud'е, а у клиента максимум какие-то там session ids в куки.

[ermouth.livejournal.com]

> и я не вижу особого тренда в эту сторону
> Всё ещё идёт мощный обратный тренд

Ты очень глубоко здесь ошибаешься. Обратного тренда нет, потому что это текущий статус-кво.

А вот люфт в сторону локального кэша очень даже есть, и не крошечный какой-то, а вовсе например Facebook Relay. Причины тут, я так полагаю, в первую очередь экономические – имея локальные кэши на клиентах, можно очень сильно понизить не-статический трафик. Да и статический кое-какой.

Массовому распространению технологии локальных БД мешает... сама эта технология.

Во-первых, IndexedDB подглючивает в большей или меньшей степени во всех без исключения браузерах. Во-вторых, API к ней удивительно уродлив и неудобен, я вообще так и не смог понять, зачем делать целиком на ивентах API к БД, которая не умеет стримить.

И в-третьих, IDB ни на что не похожа, это такой зверёк в себе. С ней без обёртки решительно невозможно иметь дело, а хороших обёрток всего две, и обе всё равно не общего назначения.

> но и базу данных с сихнронизацией между вкладками

IndexedDB это всё легко делает. Она одна на все вкладки одного домена.

[morfizm.livejournal.com]

С другой стороны, народ потихоньку начинает понимать, что в developing countries отстойный 2G, и reliable broadband не предвидится ещё много лет (10+). А если расширять юзербазу на ещё более отстающие developing countries, то можно и ещё 10+ лет прибавить. А все хотят расширяться.

Т.е. я думаю, ты прав, мы к этому придём, но я бы не стал делать краткосрочные прогнозы. Прямо сегодня вроде как мы немного не туда идём :)