Все верно, адапетр Редиски тут не причем, дело в том что действительно в Zend_Queue такого метода нету, он есть только у адапетров: $queue->getAdapter()->isExists('test7');
Адаптер в Редиске реализует интерфейс Zend_Queue и не более того. Поэтому все архитектурные кляузы принадлежат к кривоватому по моему мнению Zend_Queue.
К слову, в библиотеке Rediska есть специальный адаптер для того, чтобы работать с очередями поверх Redis, но промучившись неделю и так и не заставив работать даже тестовый пример, я окончательно решил — все, пишу свою систему!
Очень странно мы успешно используем! Что у вас не работает?
Еще одним замечанием об архитектуре и отличиях от Rediska_Queue будет то, что насколько я понял из исходников, в угоду быстродействию, они положили ценное свойство распределённости. Например, команда getQueues, которая возвращает массив всех хранимых очередей (не сообщений, а только имена очередей), работает с локальной копией списка очередей. Поэтому, если другой клиент создаст новую очередь во время работы первого, он об этом не узнает.
Вы заблуждаетесь. Советую заглянуть глубже, перед тем как делать какие-то выводы.
Все верно, делает запрос при каждом добавлении. Redis пока не поддерживает операции множественного добавления элементов в списки. Поэтому сейчас нету разницы, отправлять по мере поступления или отправлять все сразу.
class Communities
{
public function findCommunities()
{
$community = new stdClass();
$community->id = 1;
return array($community);
}
}
class Cache_Tag_Communtity extends Geometria_Cache_Frontend_Tag
{
public function __construct($community)
{
parent::__construct("community_{$community->id}");
}
}
class Cache_Slot_Communities extends Geometria_Cache_Frontend_Slot
{
public function __construct()
{
parent::__construct('communities', 60 * 60);
}
public function save($communities)
{
foreach ($communities as $community) {
$this->addTag(new Cache_Tag_Communtity($community));
}
return parent::save($communities);
}
}
$slot = new Cache_Slot_Communities();
$communities = $slot->thru(new Communities)->findCommunities();
Точно! Вообщем это аналогичное второму варианту решение, но лишенное недостатка отключенных картинок в броузере и не надо колдовать с заголовками при отдаче картинок.
Правда ифреймы могут блокироваться экстеншенами броузера, которые занимаются безопасностью и рекламой.
Я так понимаю что доступ к ресурсам порталов только для зарегистрированных пользователей. Тоесть при входе всегда спрашивается логин. Я писал что варианты интранета я не рассматривал, так как наши проекты имеют публичный доступ.
Вы меня не правильно поняли, в первом варианте я говорю о проблеме авторизации по кукам. Вы залогинились и кука поставилась на домене site1.com и сервере авторизации. Вы зашли на другой наш проект site2.com. Там кука не стоит. Чтобы поднять авторизацию вас автоматически редиректит на сервер авторизации и проверяется есть ли кука, если есть то идет обратный редирект и ставится кука на site2.com. Вы авторизованы. Если куки не принимаются, то редирект будет происходить каждый ваш реквест на site2.com.
Zend_Queue — далека до совершенства :)
Очень странно мы успешно используем! Что у вас не работает?
Вы заблуждаетесь. Советую заглянуть глубже, перед тем как делать какие-то выводы.
А что если я хочу хранить коллекцию объектов?
Правда ифреймы могут блокироваться экстеншенами броузера, которые занимаются безопасностью и рекламой.