Ну это будет ИМХО еще больший изврат — 2 синтаксиса для абсолютно одного и того же. Так что я бы лично не рассчитывал на то, что мы в ближайшие 5-10 лет увидим :: вместо \…
Упс. Ну, вообще говоря, в JsHttpRequest поддерживаются 3 транспорта: script, XMLHttpRequest, а также IFRAME — для закачки файлов аяксом на сервер. Плюс автоматом выбирается оптимальный (из тех, что поддерживает текущий браузер, в зависимости от кроссдоменности и т.д.). Но, конечно, есть и отдельный версии библиотеки, по одной на каждый вид транспорта (например, можно взять только JsHttpRequest-script.js, в которой ничего, кроме script-транспорта, нет).
По поводу того, что в этом вопросе считать «рабочим временем», есть вот какая мысль.
1. Самый простой вариант, это когда «на работе» и «не на работе» четко разделено (а так довольно часто бывает у тех, кто работает в офисе: утром пришел, вечером ушел, и дома уже о работе практически не вспоминаешь). Работа обычно имеет какую-то цель: сделать то-то, закрыть задачу такую-то и т.д. Так вот, сумма времени, когда мысли посвящены продвижению к этой цели (а человек не может думать о двух вещах одновременно), это и есть «реально работаю». Сюда включается и кодинг, и чтение документации, и поиск информации по теме, и рабочие дискуссии, и сидение за чашкой чая с карандашом (кстати, в сидение без карандаша и просто обдумывание «без инструмента» в контексте офисной работы я лично не очень верю, т.к. тут высок риск самообмана).
2. Все несколько сложнее, когда в наличии свободный график. В этом случае (при наличии должного интереса, естественно) работа может занимать все мысли постоянно (на этот раз даже без карандаша), и часто получается, что ничем другим, кроме рабочих вопросов, за день даже и не занимаешься. И тут почти невозможно нормировать время: все равно задача (если она интересная) вылезает на передний план и перетягивает на себя все ресурсы.
Там в дистрибутиве куча файлов, начинающихся с точки. Видимо, бэкапы?
Кстати говоря, для PECL-расширения ИМХО лучше распространять не полный дистрибутив, а патч. Там могут новые фичи добавиться (всякие там поддержки консистентности и т.д.), и Ваша версия быстро устареет, если она будет не в виде патча идти.
А тем временем, два человека, рассказавшие о проблемах с авторизацией, так и не прислали мне в личку то, что я просил. Пришлите все-таки, пожалуйста: без этой информации невозможно диагностировать проблему.
Тэги физически хранятся там же, где и ключи. Подробности алгоритма достаточно сложны, но вы можете: а) посмотреть в коде, как оно работает; б) посмотреть в phpt-тестах все варианты использования. Также алгоритм разработан так, чтобы случайная потеря ключа с тэгом (например, в результате вытеснения из памяти) автоматом вела к инвалидации всех зависимых от него ключей. Т.е. алгоритм консистентный.
Кстати, если memcached-серверов несколько, то можно использовать входящий в библиотеку модуль Dklab_Cache_Backend_ReplicationWrapper. Он обеспечивает репликацию операций удаления (а при желании — и записи) ключей. Вообще, в последних версиях php-модуля memcache репликация поддерживается на встроенном уровне, но с ними все та же проблема: они нестабильны, сегфолтятся и подвисают (видимо, потому до сих пор и бета). Поэтому пришлось сделать простейшую репликацию самостоятельно (благо оно несложно).
Про PECL для memcached-tag — да, совершенно верно. Там есть поддержка tag_add и tag_delete. А вот в Вашей версии memcached-tagS, вернее, в PHP-модуле для нее, — есть ли поддержка функции tagS_delete?
Memcached-tags — это, насколько я понимаю, форк от memcached-tag, совместимый по интерфейсу. Поэтому для нее Dklab_Cache_Backend_MemcachedTag подхоит (правда, Dklab_Cache_Backend_MemcachedTag не поддерживает tags_delete, но такую поддержку нетрудно реализовать, позволив методу clean() принимать список, каждый элемент которого может быть именем тэга, а может — массивом имен).
Вот чтобы разобраться, в чем же проблема, я и предлагаю сейчас прислать данные лично мне. Страшно писать в support — отправьте их мне в личку на Хабре. Чтобы понять причины проблемы, нужно ее воспроизвести, а когда нет шагов по воспроизведению, этого очень сложно добиться.
Ваше неудобство вполне понятно: для ряда людей и правда удобнее было бы общаться с кандидатами напрямую. В скором времени мы планируем много разных нововведений в разделе Работа. Думаю, решится и эта проблема. Спасибо за Ваши комментарии.
Пришлите, пожалуйста, через feedback.yandex.ru/?from=MK&side= (с пометкой «Для Дмитрия Котерова по его просьбе»):
— Ваш старый логин (почтовый адрес) и пароль к нему
— Ваш email для связи (у нас могут возникнуть дополнительные вопросы), а еще лучше — ICQ или gtalk.
Это очень интересная тема.
А можете дать прямую ссылку на документацию по by_key-функциям?
А то я за 10 минут в Гугле не нашел внятных подробностей, как оно работает. Ссылки в основном ведут на доки по UDF-функциям MySQL. Также есть ссылки на листы рассылки, из которых следует, что by_key-функции применяются для привязки некоторого набора ключей гарантировано к одному серверу. Про тэги ни слова.
Причины две:
1) получить фидбэк от профессионального сообщества, представителей которого здесь больше, чем где-либо;
2) узнать альтернативные (возможно, более эффективные) методы реализации того, что делают предложенные библиотеки.
use aa\b\ccc;
и
$a = new ddd\eee\ccc(1);
ИМХО разделитель \ вместо :: — все-таки изврат.
Но с php.net/namespaces не поспоришь…
1. Самый простой вариант, это когда «на работе» и «не на работе» четко разделено (а так довольно часто бывает у тех, кто работает в офисе: утром пришел, вечером ушел, и дома уже о работе практически не вспоминаешь). Работа обычно имеет какую-то цель: сделать то-то, закрыть задачу такую-то и т.д. Так вот, сумма времени, когда мысли посвящены продвижению к этой цели (а человек не может думать о двух вещах одновременно), это и есть «реально работаю». Сюда включается и кодинг, и чтение документации, и поиск информации по теме, и рабочие дискуссии, и сидение за чашкой чая с карандашом (кстати, в сидение без карандаша и просто обдумывание «без инструмента» в контексте офисной работы я лично не очень верю, т.к. тут высок риск самообмана).
2. Все несколько сложнее, когда в наличии свободный график. В этом случае (при наличии должного интереса, естественно) работа может занимать все мысли постоянно (на этот раз даже без карандаша), и часто получается, что ничем другим, кроме рабочих вопросов, за день даже и не занимаешься. И тут почти невозможно нормировать время: все равно задача (если она интересная) вылезает на передний план и перетягивает на себя все ресурсы.
Кстати говоря, для PECL-расширения ИМХО лучше распространять не полный дистрибутив, а патч. Там могут новые фичи добавиться (всякие там поддержки консистентности и т.д.), и Ваша версия быстро устареет, если она будет не в виде патча идти.
Кстати, если memcached-серверов несколько, то можно использовать входящий в библиотеку модуль Dklab_Cache_Backend_ReplicationWrapper. Он обеспечивает репликацию операций удаления (а при желании — и записи) ключей. Вообще, в последних версиях php-модуля memcache репликация поддерживается на встроенном уровне, но с ними все та же проблема: они нестабильны, сегфолтятся и подвисают (видимо, потому до сих пор и бета). Поэтому пришлось сделать простейшую репликацию самостоятельно (благо оно несложно).
Про PECL для memcached-tag — да, совершенно верно. Там есть поддержка tag_add и tag_delete. А вот в Вашей версии memcached-tagS, вернее, в PHP-модуле для нее, — есть ли поддержка функции tagS_delete?
1. Где хранится: habrahabr.ru/blogs/php/57142/#comment_1534035
2. Нет, пока этой поддержки нет, но см. habrahabr.ru/blogs/php/57142/#comment_1538275 — кстати, как называется соответствующая PHP-функция для tagS_delete? и есть ли ссылка на PECL-расширение?
И — что послужило в Вашем случае «последней каплей»? Вы столкнулись с каким-то неудобством, или же с отсутствием какого-то функционала?
— Ваш старый логин (почтовый адрес) и пароль к нему
— Ваш email для связи (у нас могут возникнуть дополнительные вопросы), а еще лучше — ICQ или gtalk.
Разберемся, в чем проблемы.
А можете дать прямую ссылку на документацию по by_key-функциям?
А то я за 10 минут в Гугле не нашел внятных подробностей, как оно работает. Ссылки в основном ведут на доки по UDF-функциям MySQL. Также есть ссылки на листы рассылки, из которых следует, что by_key-функции применяются для привязки некоторого набора ключей гарантировано к одному серверу. Про тэги ни слова.
1) получить фидбэк от профессионального сообщества, представителей которого здесь больше, чем где-либо;
2) узнать альтернативные (возможно, более эффективные) методы реализации того, что делают предложенные библиотеки.