Как браузер должен взаимодействовать с локальным устройством?

#architecture #cross-browser #cross-platform

#архитектура #кроссбраузерность #кроссплатформенность

Вопрос:

Как это должно быть реализовано?

  1. К компьютеру пользователя подключено USB-устройство («дверной звонок»).
  2. Пользователь переходит на веб-страницу клиента и нажимает на ссылку.
  3. Появляется уведомление «Пожалуйста, нажмите на дверной звонок».
  4. Пользователь нажимает на дверной звонок, веб-сайт получает уведомление.

«Дверной звонок» на самом деле является сложным устройством со своим собственным SDK, и оно отправляет обратно большой объем данных. Производитель устройства предоставляет пакеты SDK как для Windows, так и для OSX. Я могу написать собственный код для любой платформы для взаимодействия с устройством на уровне операционной системы.

Планируйте

  1. LocalWatchdog процесс выполняется на компьютере пользователя.
  2. Плагин браузера улавливает событие веб-страницы
  3. Плагин для браузера что-то делает (используя NPAPI?) чтобы сигнализировать LocalWatchdog
  4. LocalWatchdog выводит уведомление и получает событие нажатия дверного звонка
  5. LocalWatchdog делает что-то, чтобы сообщить плагину, что был нажат дверной звонок.
  6. Плагин сообщает веб-сайту.

План Б

  1. Веб-сайт загружает Java-апплет, который выполняется локально на компьютере пользователя.
  2. Апплет выдает уведомление.
  3. Апплет делает что-то, чтобы перехватить событие нажатия дверного звонка.
  4. Апплет сообщает веб-сайту, что был нажат дверной звонок.

Приветствуются другие планы, но в любом случае, что это за нечто?

  • Допустим любой язык.
  • Нетривиальный процесс установки приемлем.
  • Должен работать на OSX и Windows. Если мне придется написать это дважды, я это сделаю.
  • Должен работать с Chrome, Firefox и IE. Если мне придется написать это три раза, я это сделаю.

Комментарии:

1. Мне любопытно: даже с подписанным Java-апплетом вы можете выполнять машинный код?

2. Да, через JNI. Но теперь Google продвигает вместо этого собственный клиентский подход Chrome.

3. Мой собственный клиент. Тем не менее, интересно.

Ответ №1:

Если у вас есть локальный процесс, я бы сказал:

  1. Запустите локальный веб-сервер, который взаимодействует с оборудованием и использует соответствующий междоменный XML-файл.
  2. Используйте вызов Ajax, чтобы запросить обращение к нему из браузера и запросить нажатие кнопки
  3. Когда локальный веб-сервер получит запрос, отправьте аппаратному обеспечению соответствующее сообщение (я предполагаю, что это какая-то вещь типа USB HID).
  4. Сообщите пользователю в браузере, затем снова откройте запрос с длительным опросом на локальный веб-сервер и дождитесь ответа.
  5. Если пользователь нажимает кнопку, верните данные в запрос браузера.
  6. Прибыль (мы надеемся).

Комментарии:

1. Итак, когда страница запрашивает http://localhost:9999/mydevice , локальный процесс обрабатывает это? Хм, определенно возможно…

Ответ №2:

Нужно ли их вообще соединять?

Пользователь в браузере нажимает на ссылку. Это ставит событие в очередь в серверной системе.

Независимо от этого, процесс LocalWatchdog на хосте периодически (каждую минуту?) опрашивает серверную часть через REST API или что-то подобное?) Если есть ожидающая выполнения операция, она подтверждает это (и удаляет ее с сервера), а затем появляется диалоговое окно «нажать кнопку дверного звонка».

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

Комментарии:

1. Итак, если у 10 000 пользователей есть дверной звонок, мой хост опрашивается 10 000 раз в минуту, 24/7? (Я неправильно понял?)

2. Интервал зависит от вас. Но я понимаю вашу точку зрения. Идея Femi неплохая.