Rich Internet Application и управление контентом

[rglab]

Я сам пишу ныне все AJAX-базированные приложения исключительно на JSON. Скажем, JS код билиотеки управления деревом структуры с Drag&Drop и контекстным меню сократился почти в 2 раза, скорость работы приложения выросла раза в три, код легче понять (а это важно, так как для open source проекта пишется) и т.д. Однако в нас компании практикуется и XML для унификации контроллера, возможности разибрать его ответ в сторонних приложениях

[hmelyoff]

AJAX хорошо использовать по смыслу а не везде подряд! как нынче модно! браузеры пока еще не поддерживают (в план организации интерфейса) его...
Допустим хочешь показать другу то, что увидел... а ссылка то не сменилась с момента захода на сайт!

Мое мнение, AJAX хорошо в меру...
Ждем поддержку браузерами аякса...

[smart]

А при чем тут браузеры? Это, скорее, дело приложения. Да, конечно было бы здорово, если бы javascript-код мог бы менять урл в адресной строке без фактического перехода. Но и сейчас есть варианты обхода этой проблемы - делаем урлы с якорями, и повсюду пихаем ссылки permalink. В общем, жить можно ;)

[pixelcube]

Пишите на флеше :) все таки AS3 это ООП в отличие от JS.
Нет головных болей от платформы/браузера...флеш либо установлен - либо его нет.

[KAFLAN]

В общем случае:
- Флеш в разработке дороже (даже если брать среднюю цену на рынке)
- Флеш сам по себе тяжелее (я имею ввиду размер swf)

> флеш либо установлен - либо его нет.
Браузер установлен в подавляющем большинстве случаев.

> Нет головных болей от платформы/браузера...
Согласен... Это огромный плюс.

[smart]

> флеш либо установлен - либо его нет.

Может в это сложно поверить, но я наелся досыта проблемами, возникающими с флешом в разных браузерах. Например, в ФФ 1.5 флешка высотой больше одного экрана не может корректно реагировать на мышь в промежуточных положениях скроллинга. В некоторых операх у флешки съезжает отображение текста и т.п. Так что не так все просто!

[AndrewStephanoff]

а кто сказал, что js это не ООП?

[q_styler]

>>а ссылка то не сменилась с момента захода на сайт!
а для этого можно делать специальные штуки типа "ссылка на эту страницу"

[hmelyoff]

А ты ее покажи пользователю? И заставь ее найти?
Что первым делом станет делать посетитель? Копировать то, что у него перед глазами (браузерную строку)...
Якори конечно выход, но урлы становятся крайне нечитаемыми...

[AndrewStephanoff]

а как сокращается размер передаваемой информации :)

[DeadMoroz]

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

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

[mot]

Пока этого нет, но рождается :)
http://cometd.com/

[hmelyoff]

По запросу браузера, асинхронно. :)
Поставил реакцию на приход данных и пусть пользователь делает что ему надо.

[rglab]

Имеется ввиду - когда нет явного запроса (Reverse AJAX). Конечно на стороне клиентского приложения регулярно совершаются обращения к серверу, но пользователь в этом не принимает участия. Для него это выглядит, так как если бы сервер вдруг постучался в браузер и заявил что лимит места на сервере закончился или что-либо еще.

[smart]

Есть разные техники - как те, что тут упомянули (периодический опрос сервера), так и более "синхронные".

Например, ajax-приложение может делать запрос к серверу, а сервер - не отвечать сразу, а держать это соединение открытым, пока для этого клиента не появятся данные. Как только появилась информация для передачи клиенту - сервер отдает ответ и закрывает соединение. А клиент, получив информацию, тут же открывает новое соединение для ожидания новой порции данных (кстати, так работает внутренняя переписка на damochka.ru - но там не js, а java).

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

[theOnlyBoy]

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

[AHTOH]

Ничего страшного. Обычный сервер Apache поддерживает 256 постоянных соединений, но простым жестом руки, изменяющим эту константу, можно добиться любого количества открытых соединений. Это часто используется в чатах, где 300-400 одновременных KeepAlive соединений вполне обычное дело. Но есть более эффективные техники, позволяющие получать тот же эффект с меньшими затратами.

[smart]

Делать чат на апаче крайне накладно - поскольку апач каждое соединение обрабатывает в отдельном процессе (1.3 так делает всегда, да и 2.x обычно настраивают именно так). Для операционной системы эти сотни-тысячи процессов - очень большая нагрузка.

Поэтому для постоянных соединений единственный вариант - мультиплексирование, когда один процесс по очереди обрабатывает много соединений. Так работают web-серверы nginx, lighttpd и другие.

[smart]

И в чем проблема? ;) Держат, еще как! На самом деле, держать кучу таких открытых соединений не трудно, если аккуратно с ними работать. Конечно, это должен быть не apache+cgi или apache+mod_php, а, чаще всего, какой-то отдельный демон, написанный на компилируемом языке.

Кстати, приходите на конференцию, в первый день Игорь Сысоев расскажет, как настроить FreeBSD для работы с 100-200 тысячами соединений.

[yshilyaev]

РГЛаб начал PR-активности на Хабре... :)
Подскажите кто из вас под ником этим сидит?

[valodka]

http://www.cmsdevelopment.com/ru/article…