Приветствую.
Подскажите, пожалуйста, как лучше организовать взаимодействие между JS-скриптом на HTML-странице и локальной службой Windows?
Нужно отправить текстовый запрос и получить ответ.
Можно запустить в рамках службы HTTP-сервер, но хотелось бы обойтись менее громоздким решением.

Здравствуйте, LWhisper, Вы писали:

LW>Приветствую.
LW>Подскажите, пожалуйста, как лучше организовать взаимодействие между JS-скриптом на HTML-странице и локальной службой Windows?

Qt+Webkit.

Здравствуйте, LWhisper, Вы писали:

LW>Приветствую.
LW>Подскажите, пожалуйста, как лучше организовать взаимодействие между JS-скриптом на HTML-странице и локальной службой Windows?
LW>Нужно отправить текстовый запрос и получить ответ.
LW>Можно запустить в рамках службы HTTP-сервер, но хотелось бы обойтись менее громоздким решением.

Остальные варианты (ActiveX,SOAP,socket.io т.д.) еще более громоздки, готовых библиотек, реализующих функционал HTTP сервера — куча, это все делается за пару часов

Здравствуйте, LWhisper, Вы писали:

Если .net, то смотрите на NancyFx.

Здравствуйте, DTB, Вы писали:
DTB>Остальные варианты (ActiveX,SOAP,socket.io т.д.) еще более громоздки, готовых библиотек, реализующих функционал HTTP сервера — куча, это все делается за пару часов
ActiveX морально устарел, SOAP, как вариант, интересен, а сокет более чем устроил бы. Существует способ поточного взаимодействия между JS и сервисом, используя TCP-Socket?
Реализовать HTTP-сервер не сложно, просто это использование не по назначению.

И да, речь идёт о ванильном JS без node.js, socket.io, jquery и прочей хрени.

Здравствуйте, Sharov, Вы писали:

S>Если .net, то смотрите на NancyFx.
Хм. А зачем, если существует стандартный HttpListener?
Ведь у меня Windows Service, а не Web-приложение.
Насколько я понимаю, NancyFx — это замена ASP.NET. У меня же нет ни HTML-страниц, ни прочего WEB-контента. Лишь клиент, который присылает текстовую строчку и ждёт ответной строки.

Здравствуйте, LWhisper, Вы писали:

S>>Если .net, то смотрите на NancyFx.
LW>Хм. А зачем, если существует стандартный HttpListener?
LW>Ведь у меня Windows Service, а не Web-приложение.

Как еще одна альтернатива — сделать встроенный REST сервис на основе WCF: ServiceHost + [WebInvoke] метод(ы) + webHttp конечная точка.

Здравствуйте, LWhisper, Вы писали:

LW>Хм. А зачем, если существует стандартный HttpListener?
LW>Ведь у меня Windows Service, а не Web-приложение.
LW>Насколько я понимаю, NancyFx — это замена ASP.NET. У меня же нет ни HTML-страниц, ни прочего WEB-контента. Лишь клиент, который присылает текстовую строчку и ждёт ответной строки.

Логично, посмотрите на websocket'ы и сервер для .net -- https://github.com/kerryjiang/SuperWebSocket

Здравствуйте, LWhisper, Вы писали:

LW>И да, речь идёт о ванильном JS без node.js, socket.io, jquery и прочей хрени.

Как бы есть TCPSocket : https://developer.mozilla.org/en-US/docs/Web/API/TCPSocket

chrome.experimental.socket.create('tcp', '127.0.0.1', 8080, function(socketInfo) {
  chrome.experimental.socket.connect(socketInfo.socketId, function (result) {
        chrome.experimental.socket.write(socketInfo.socketId, "Hello, world!");         
    });
});

Но сомневаюсь что мы доживем до его повсеместного появления. Ибо дыра в безопасности.

Проще и сейчас ничего кроме http://local:1234 ничего сделать нельзя.

Здравствуйте, LWhisper, Вы писали:

LW>Приветствую.
LW>Подскажите, пожалуйста, как лучше организовать взаимодействие между JS-скриптом на HTML-странице и локальной службой Windows?
LW>Нужно отправить текстовый запрос и получить ответ.
LW>Можно запустить в рамках службы HTTP-сервер, но хотелось бы обойтись менее громоздким решением.
HTTP — это НЕ громоздкое решение. Вы его путаете с HTML, поэтому вам кажется всякое.
Сам по себе он отличный протокол:
1. Работает из коробки в JavaScript. Это означает, что вы сможете его отлаживать без проблем. Любые "менее громоздкие" протоколы съедят вам мозг, когда вы будете пытаться разобраться, что за хрень идет в соединении, или почему в джаваскрипте так и не появились нужные вам данные.
2. Позволяет иметь очень маленький footprint. Вы не обязаны реализовывать всевозможные кунштюки — начинаете с обработки банального GET, игнорируя все хидеры, а на всё остальное отдаёте 400 Bad Request. То есть код сервера может быть построен вообще на голых сокетах, без каких-либо фреймворков.
3. Позволяет вам легко расширять протокол. Вам не надо мучиться, изобретая способ задетектить версию локального сервиса — достаточно просто сохранять обратную совместимость по урлам.
4. Не требует удержания соединения, так что вам не придётся мучиться с восстановлением потерянного соединения при закрытии клиента или рестарте сервиса.
5. Решает ещё с десяток проблем, о которых вы пока не задумывались, но которые возникнут по мере роста ваших потребностей.

Здравствуйте, LWhisper, Вы писали:

LW>Хм. А зачем, если существует стандартный HttpListener?

Озвучьте платформу. Если .net то можно попробовать обойтись HttpListener, если с++ то можно использовать Proxygen от fb