[Слесарь 9]

Необязательно для этого. В автономных системах, где оператор не сидит постоянно за компом, сам комп убран от шаловливых ручек, и работает в режим 24/7/365, и возможно даже под охраной ;-). Зачем сидеть человеку и наблюдать за температурой? Случился сбой, пришла СМС, mail, другой вид оповещения ответственному лицу, он начал принимать меры.

Обычно автономные системы имеют встроенный дисплей для вывода данных и ввода параметров. Если многофункциональные, то подключаются к ПК по COM порту. Возможно физически это USB.

Хотя не отрицаю, вывод данных на ПК в браузер по сети может быть полезен, вот и хочется узнать для каких случаев особенно?

[Quasar 20]

Обычно автономные системы имеют встроенный дисплей для вывода данных и ввода параметров. Если многофункциональные, то подключаются к ПК по COM порту.

 

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

- Система может стоять в одном городе, а оператор-инженер стоять в другом :-) ;

- Много пользователей, в том числе и разграниченных по правам, работающих одновременно;

- Кросс-платформенность, веб-интерфейсы работают на Mac OS, Linux и Windows.

 

[Слесарь 9]

- Кросс-платформенность, веб-интерфейсы работают на Mac OS, Linux и Windows.

А вот теперь скажите, в каких-таких МК системах может потребоваться кроссплатформенность?

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

[toweroff 1]

А как же всякие сертифицированные AES и иже с ними вместе с обычными браузерами? https?

Если уж очень приспичит, отчего ж не вкрутить в embedded? Или я что-то не понимаю...

[Quasar 20]

А вот теперь скажите, в каких-таких МК системах может потребоваться кроссплатформенность?

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

 

В таких, которые делаются не под конкретного заказчика, а продаются как продукт во много разных ведомств и предприятий. Вы мне все толкуете про какие-то вещи, заточенные под узкую задачу, с обязательным изобретением велосипеда в процессе разработки. Естественно, если к вам приходит заказчик и говорит хочу COM порт, вы ему не откажете. А если вы планируете железку, которая работает, как я выше писал в standalone режиме у одних заказчиков, а потом та же железка работает в составе разных систем у других заказчиков, это называется универсальное решение.

 

Где-то показания датчиков хотят просто видеть отдельно, где-то хотят их автоматически обрабатывать и выводить в виде общей таблицы, где-то датчиков 50, а где-то 500. Где-то оператор сидит в том же доме где датчики установлены, где-то в другой части света. Эти вопросы уже не касаются веб-интерфейсов как таковых. Это вопрос универсальности. Браузеры есть везде и у всех. При должном подходе, обмен данными по http можно организовать так, что бы машины могли обмениваться с машинами, автоматизируя массу вещей.

Изменено 9 июля, 2013 пользователем Quasar

[AlexandrY 3]

Где-то показания датчиков хотят просто видеть отдельно, где-то хотят их автоматически обрабатывать и выводить в виде общей таблицы, где-то датчиков 50, а где-то 500.

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

 

Тут я со Слесарем согласен. WEB интерфейс очень часто не юзабелен.

 

Он конечно хорошая фича когда надо привлечь клиентов, в нем можно сделать красиво и проч.

Но когда дело доходит до работы в больших разнородных системах админы таких систем категорически не хотят пользоваться WEB интерфейсами дивайсов.

Потому что зоопрарк дивайсов какждый со своим WEB-ом в принципе не облегчает администрирование.

 

Вот SNMP с удовольствием интегрируют. Потому что там все унифицировано

 

Серверы в дивайсах вообще в наше время представляют сплошную головную боль в связи с агрессивными публичными сетями.

 

Поэтому Google и компании поменьше типа Digi развивают свои протоколы на базе клиентских сокетов в дивайсах, без всяких встроенных в дивайсы серверов.

Кстати Digi дает сорсы своего двунаправленного протокола для подключения к их облакам.

И WEB страницы целесообразно держать только в облаках.

[Quasar 20]

Тут я со Слесарем согласен. WEB интерфейс очень часто не юзабелен.

 

Он конечно хорошая фича когда надо привлечь клиентов, в нем можно сделать красиво и проч.

Но когда дело доходит до работы в больших разнородных системах админы таких систем категорически не хотят пользоваться WEB интерфейсами дивайсов.

Потому что зоопрарк дивайсов какждый со своим WEB-ом в принципе не облегчает администрирование.

 

Потому что у всех сильно свой подход к изготовлению WEB-интерфейсов. Это конечно +1 в сторону SNMP. В плане админов, уж не знаю, вполне себе юзают WEB интерфейсы и не жалуются, ну по крайней мере на моей планете :-)

 

Вот SNMP с удовольствием интегрируют. Потому что там все унифицировано

 

Серверы в дивайсах вообще в наше время представляют сплошную головную боль в связи с агрессивными публичными сетями.

 

Поэтому Google и компании поменьше типа Digi развивают свои протоколы на базе клиентских сокетов в дивайсах, без всяких встроенных в дивайсы серверов.

Кстати Digi дает сорсы своего двунаправленного протокола для подключения к их облакам.

И WEB страницы целесообразно держать только в облаках.

 

Да, от публичных сетей надо убирать все за VPN, ибо несанкционированный доступ или просто отказ в обслуживании случаются часто с слабыми embedded девайсами. И клиентские сокеты здесь не спасут, особенно от отказа в обслуживании :-(

Изменено 9 июля, 2013 пользователем Quasar

[AlexandrY 3]

В плане админов, уж не знаю, вполне себе юзают WEB интерфейсы и не жалуются, ну по крайней мере на моей планете :-)

 

Да, от публичных сетей надо убирать все за VPN, ибо несанкционированный доступ или просто отказ в обслуживании случаются часто с слабыми embedded девайсами. И клиентские сокеты здесь не спасут, особенно от отказа в обслуживании :-(

 

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

Но любой смертный не любит слишком большого разнообразия.

 

Получить DDoS атаку это большая честь для дивайса.

Все проще.

Открытые порты притягивают мусорный трафик.

Собственный провайдер может такой создать даже в пределах внутренней сети.

А VPN это другая тема.

 

 

[Quasar 20]

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

Но любой смертный не любит слишком большого разнообразия.

 

Получить DDoS атаку это большая честь для дивайса.

Все проще.

Открытые порты притягивают мусорный трафик.

Собственный провайдер может такой создать даже в пределах внутренней сети.

А VPN это другая тема.

Ну так, в результате прихода большого количества трафика и будет отказ в обслуживании. Совершенно не важно атака это, или само получилось. Результат будет один. Просто так провайдер трафик на открытые порты не создаст. Скорее будут проблемы с широковещательным трафиком, и некоторые умудряются в сеть пихать мультикаст трафик, без IGMP и должного оборудования поддерживающего его маршрутизацию. Но это правда совсем клиника.

[VCucumber 0]

AJAX

 

как выглядит ajax со стороны мк ?

 

[VCucumber 0]

в общем, ajax это наверно хорошо, но таки ssi всё равно нужен

суть проблемы - нашёл баги в httpd.c lwip

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

- не передаётся подстановка, если в файле после неё нет текста

- тэги не исключаются из результата

хотя последнее м.б. и фича, но всё равно неправильная

 

нет ли у кого свеженькой или исправленной либы ?

 

[VCucumber 0]

в общем, не стал править те кривули - обошёл косяки разбором результата запроса на клиенте

клиент толстый - так в разы быстрее

 

[VCucumber 0]

утро вечера мудренее(с) - пофиксил косяки, распрямил фичи - теперь всё работает как надо