> Хм. А чегой-та так полыхнуло, если браузер предназначен для работы в режимеВ режиме панели управления космического корабля - больше соответствует наблюдаемой реальности.
> 1 хтмл"? Причем тут реалтаймовые значения датчиков, если с ними на
> низком уровне работает специальная кэширующая (и увязывающая в БД) софтина,
А юзер, особенно ремотный, все-равно зачастую захочет и будет видеть нечто такое как-то так. И я не понимаю почему веб должен быть принципиально обделен на message-based протоколы, которые там сейчас вообще принципиально не реализуемы в нормальном виде из-за завязки на TCP.
Грубо говоря, мне так то тоже было бы удобно пульнуть в клиента апдейт в режиме fire and forget а если он профакался, может это не так уж и страшно, смотря что это. И пульнуть забуферизовавшийся при тупняках канала цать минут мег отсчетов может иной раз вести только к напрасному клину клиента на его парсинг, при том что он не заинтересован в том что было цать минут назад, только то что "здесь и сейчас".
> у которой изначально стояла цель НЕ "скачать документ-отрисовать документ", а обработка
> пакетов в реальном времени (приходящих откуда угодно - с СОМ, с
> UART, с промышленной сетки по самописному протоколу на уровне или ниже
> чем пресловутый TCP)?
Спасибо, я в куре и протоколов такого плана видел поболее вашего, и даже свои иногда запиливаю. А вот TCP я таки недолюбливаю за характетный букет дурацких свойств. И в частности из него принципиально нельзя сделать message-based протокол. Более того, делать даже какой-нибудь чатик как stream а не message based вообще-то является инженерной идиотией, называя вещи своими именами. Просто людям приходится натягивать сов на глобус т.к. по другому их "подложка" не умеет. А тут вот идея научить и веббраузеры этому наконец.
