ошибаетесь, давно не требует http://www.ibm.com/developerworks/ru/library/wa-ajaxintro10/ , http://api.jquery.com/jQuery.getJSON/
да в принципе все равно на чем писать, но с Ajax проще - весь интерфейс это набор статических файлов, а генерация JSON проще чем генерация статического HTML

Сообщение отредактировал polyname - Feb 8 2013, 08:22

Да видать смысл аббревиатуры AJAX уже прочно исказился.

Но тем не менее роль CGI не только в том чтобы сгенерировать ответ в виде HTML страницы или JSON набора данных, но еще и выполнить действия непосредственно в микроконтроллере. Только на нативном языке это и можно сделать.
А сам Ajax по сути нужен только для добавления динамики в страницы. Если речь идет о редактировании параметров, то Ajax не при деле.

Да XML я думаю уже давно устарел. JSON имеет ряд преимуществ перед XML, например, меньший размер при том же объеме полезных данных. Но ключевое для меня это простота, мне читать JSON при отладке куда проще чем XML. Кстати для отладки из браузеров Opera, Mozilla и Chrome последний кажется мне наиболее удобным.
JS использую потому-что считаю необходимым проверять валидность данных до их отправки на сервер.
Да и без JS наверно невозможно сделать всплывающие окна и обновление лишь части html страницы, например в моем случае обновление состояния датчиков.
Javascript очень простой язык, а с jquery становится еще приятней.
Обновлять все страницу целиком как-то не серьезно.

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

Я сторонник минимализма и концентрации как модно говорить "бизнес логики" в одном месте.
Проверка валидности данных в HTML странице перед отправкой, приводит к тому, что при изменении
структуры данных придется править две программы: в микроконтроллере и в скрипте на странице.
Пока данных мало или проект одиночный то можно терпеть.
Но скажем если параметров под сотню ( а это уровень сложности скажем так рядового частотного преобразователя в автоматизации), то проблема как говориться встает.
Вообще увлечение скриптами на стороне клиента чревато всегда двойной работой.
Хотя jquery сам люблю и применяю.

Я делал интерфейс без файлов. Интерфейс был одно приложение. В будущем планировалось отдельные модули упаковать в отдельные динамические библиотеки или СОМ объекты.

полностью динамический контент, все GET запросы пользователя обрабатывались и генерировался контент на ходу, согласно C++ программы и данных из БД.
Модуль который генерировал тот или иной объект видимый пользователю, так же и обрабатывал клики пользователя по этому объекту, разбирая POST запросы от пользователя. 100% объектно-ориентированный подход.

Для динамических страниц применение скриптов на стороне клиента оправдано - памяти то не бесконечно(на микроконтроллере). Проще формы и статический контент грузить в код, а динамически менять через ajax переменные-параметры. При этом ускорение работы страниц (из-за уменьшения объема обмена в десятки раз) огромное, правда скрипты загружаются долго в самом начале, зато потом даже сложная тяжелая форма летает . Например для маленьких микроконтроллеров без MMU linux и прочего по другому вообще никак, если хотите веб морду с серьезным дизайном (а не поделку на голом html). Да, и никто не запрещает написать генератор кода (например пишу для создания кусков страниц на Си в CGI из HTML контента) чтобы не делать как вы говорите - двойной работы. Я сторонник того чтобы программист пиал как можно больше утилит и программ )) Это повышает его умения.

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

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

Вы не поняли, я говорил о том что под скрипты на стороне клиента, нет полной гарантии что клиент сможет пользоваться сервисом. Только с помошью протестированного рекомендованного ПО

а где могут быть проблемы ? TCP - очень надежный протокол.
вот генерация HTML контроллером - это да, костыли еще те...

Сообщение отредактировал polyname - Feb 8 2013, 17:50

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

У меня на Linux уходило гораздо больше времени чтобы заполнить буфер данными чем на запуск ОС, без этого получите не интернет-радиоприемник а интернет-радио-заику

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




Я использую буфер 64 кБайта, этого хватает на несколько секунд воспроизведения при обрыве потока данных, без заикания.

Что-то слишком мало 64 кб, не помню точно сколько делал - у меня уходило на заполнение секунд 5, в Linux пару мегабайт отдать - ничего не значит плеер этот http://mpd.wikia.com/wiki/Music_Player_Daemon_Wiki им можно по сети управлять. Помоему 2 метра и отдавал под буфер а играть начинал после заполнения 20%.

Сообщение отредактировал sasamy - Feb 14 2013, 18:07