Pull to refresh

Comments 23

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

Мое мнение, AJAX хорошо в меру...
Ждем поддержку браузерами аякса...
А при чем тут браузеры? Это, скорее, дело приложения. Да, конечно было бы здорово, если бы javascript-код мог бы менять урл в адресной строке без фактического перехода. Но и сейчас есть варианты обхода этой проблемы - делаем урлы с якорями, и повсюду пихаем ссылки permalink. В общем, жить можно ;)
Пишите на флеше :) все таки AS3 это ООП в отличие от JS.
Нет головных болей от платформы/браузера...флеш либо установлен - либо его нет.
В общем случае:
- Флеш в разработке дороже (даже если брать среднюю цену на рынке)
- Флеш сам по себе тяжелее (я имею ввиду размер swf)

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

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

Может в это сложно поверить, но я наелся досыта проблемами, возникающими с флешом в разных браузерах. Например, в ФФ 1.5 флешка высотой больше одного экрана не может корректно реагировать на мышь в промежуточных положениях скроллинга. В некоторых операх у флешки съезжает отображение текста и т.п. Так что не так все просто!
>>а ссылка то не сменилась с момента захода на сайт!
а для этого можно делать специальные штуки типа "ссылка на эту страницу"
А ты ее покажи пользователю? И заставь ее найти?
Что первым делом станет делать посетитель? Копировать то, что у него перед глазами (браузерную строку)...
Якори конечно выход, но урлы становятся крайне нечитаемыми...
а как сокращается размер передаваемой информации :)
и, наоборот, сервер может передать данные браузеру в любой момент, а не только лишь тогда, когда запрашивается новая страница


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

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

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

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

Кстати, приходите на конференцию, в первый день Игорь Сысоев расскажет, как настроить FreeBSD для работы с 100-200 тысячами соединений.
РГЛаб начал PR-активности на Хабре... :)
Подскажите кто из вас под ником этим сидит?
Sign up to leave a comment.

Articles