[PHP] Есть ли распространённые реализации этого типа велосипедов?
т.е. ты хочешь чтоль стейт хранить в процессе? Имхо это не есть верно. Масштабируемости можно достигнуть как раз отделив стейт от процессинга запросов. Иначе получается, что у тебя куча процессов, забинденных на пользователей, висит и нихрена не делает, если их юзеры не активны. Плюс еще у тебя появляется головняк с менеджемнтом упавших процессов, один хер восстановление стейта и т.д.
В чем проблема хранить сессионные данные и поднимать их по конкретной сессии?
В чем проблема хранить сессионные данные и поднимать их по конкретной сессии?
Ну один процесс может обслуживать много пользователей, это не сложнее в плане реализации, так что перерасход будет не настолько огромным, как может показаться (не по 10м на пользователя). Да, какой-то перерасход будет, это естественно.
Зачем? Тут как раз просто, чтобы приблизить архитектуру программы на веб к более удобным традиционным GUI, это актуально, когда идёт активный обмен данными с пользователем. Меня постоянно не покидает ощущение, что куча всяких обвязок, созданных для сохранения сессий, кеширования и т.п., по сути сложные и при этом немного неполноценные костыли, которыми пытаются имитировать классические GUI. Хочется чего-то другого.
Сохранять в базу нужно только ключевые вещи. А многие второстепенные можно и потерять (как обычная программа на компьютере может повиснуть или прибиться, неприятно, но главное, чтобы ключевые данные не пострадали). Да, какая-то головная боль есть в плане реализации диспетчера задач, но это разовые вещи. Мне кажется, что это окупается удобством разработки самих приложений.
Зачем? Тут как раз просто, чтобы приблизить архитектуру программы на веб к более удобным традиционным GUI, это актуально, когда идёт активный обмен данными с пользователем. Меня постоянно не покидает ощущение, что куча всяких обвязок, созданных для сохранения сессий, кеширования и т.п., по сути сложные и при этом немного неполноценные костыли, которыми пытаются имитировать классические GUI. Хочется чего-то другого.
Сохранять в базу нужно только ключевые вещи. А многие второстепенные можно и потерять (как обычная программа на компьютере может повиснуть или прибиться, неприятно, но главное, чтобы ключевые данные не пострадали). Да, какая-то головная боль есть в плане реализации диспетчера задач, но это разовые вещи. Мне кажется, что это окупается удобством разработки самих приложений.
Сохранять в базу нужно только ключевые вещи. А многие второстепенные можно и потерять (как обычная программа на компьютере может повиснуть или прибиться, неприятно, но главное, чтобы ключевые данные не пострадали). Да, какая-то головная боль есть в плане реализации диспетчера задач, но это разовые вещи. Мне кажется, что это окупается удобством разработки самих приложений.Сделай memcache какой-нибудь и храни состояние там, иногда сбрасывай в базу что надо.
по сути сложные и при этом немного неполноценные костыли, которыми пытаются имитировать классические GUI. Хочется чего-то другого.а чего хочется?
> а чего хочется?
Хочется большей гибкости, чтобы приложение изнутри больше напоминало типичное GUI приложение.
В скриптовой модели должны присутствовать механизмы по сохранению состояний в строки, и по восстановлению состояния из сохранённых строк. Что есть некоторая лишняя возня, которая может быть довольно сложной в ряде случаев, и в, общем, главный костыль и есть. При этом, такую распаковку необходимо вести при каждом событии, которых может быть очень много.
Хочется большей гибкости, чтобы приложение изнутри больше напоминало типичное GUI приложение.
В скриптовой модели должны присутствовать механизмы по сохранению состояний в строки, и по восстановлению состояния из сохранённых строк. Что есть некоторая лишняя возня, которая может быть довольно сложной в ряде случаев, и в, общем, главный костыль и есть. При этом, такую распаковку необходимо вести при каждом событии, которых может быть очень много.
Хочется большей гибкости, чтобы приложение изнутри больше напоминало типичное GUI приложение с единой точкой отказа.
Хочется большей гибкости, чтобы приложение изнутри больше напоминало типичное GUI приложение.Ну очевидно, что ты больше десктопный разработчик, а не под веб.
И пытаешься со своим уставом в чужой монастырь...
Как правильно тебе заметили, это будут те еще костыли, которые нужны тебе только для лучшего понимания в условиях твоих знаний.
Вывод - расширяй кругозор
Тут нет какого-то устава, на самом деле. Тем более, сейчас веб-приложения становятся более похожими на десктоп (посмотри, например, aviari, todo.ly). ТС можно порекомендовать gwt-php, у них свой протокол на основе xml для передачи состояния (почти идентичный gwt-шному, но сервер можно писать на php).
В поддержку предыдущего поста могу сказать, что нужно понимать хорошо, зачем нужен тот или иной fancy framework.
В поддержку предыдущего поста могу сказать, что нужно понимать хорошо, зачем нужен тот или иной fancy framework.
Ну очевидно, что ты больше десктопный разработчик, а не под веб.Не очевидно. Если в PHP не принято (тяжело и через жопу) хранить данные между запросами в памяти процесса, то это не значит, что этим не пользуются в других языках.
нету принято и не принято.
есть инструмент, цели и условия его использования.
в php нет процессов в принципе.
код исполняется и умирает.
Для того, чтобы получить от него больше, чем он есть, используются другие инструменты - memcache и акселераторы.
есть инструмент, цели и условия его использования.
в php нет процессов в принципе.
код исполняется и умирает.
Для того, чтобы получить от него больше, чем он есть, используются другие инструменты - memcache и акселераторы.
Оставить комментарий
alexkravchuk
возник такой вопрос.Понятно, что модель CGI много неудобств порождает, когда надо работать с сеансами, где много разнородных контекстных данных используется. Различного рода сериализации с дальнейшим сохранением, всё это как-то криво и неудобно. Существует ли какие-нибудь средства, которые позволяют порождать какие-нибудь процессы, работающие по сценариям обработки событий, чтобы пользователь работал уже непосредственно с конкретным процессом?
Что я имею в виду.
Работают два типа скриптов.
Front-end скрипты принимают запросы от пользователей, проверяют, завязан ли на пользователя какой-то back-end процесс, генерируют структуру, близкую к $_REQUEST, $_SERVER и т.п. и сериализуют её.
Если на пользователя уже завязан какой-то back-end процесс, то front-end'ы устанавливают с ними через сокет соединение, шлют им структуру с запросом и ждут тело сгенерированной страницы.
Back-end'ы принимают запрос, раскодируют структуру с запросом и создают событие, "запрос от пользователя", направляют его на точку входа (очень похожую на вход от обычного вызова скрипта, без всяких подобных прокси). Далее скрипт генерирует страницу, вывод даже можно банально с помощью ob_ функций перехватывать, и отсылают вывод front-end'у. А сам процесс переходит в состояние ожидания нового события от пользователя, сохраняя все нужные для работы контекстные данные.
Плюсов много — и другая технология работы, и нет особого усложнения по сравнению с обычными скриптами, и хорошая масштабируемость.
В общем, идея достаточно тривиальна, и вроде бы даже и проста в реализации. В других языках, вроде питона, иногда аналогичные схемы запуска используются. А раз так, то наверное уже и кем-нибудь всё это накодировано?
Вопрос к знающим, есть ли средства поддержки подобного на PHP?