Пообщавшись с людьми и послушав доклады на РИТ-е и Хайлоаде, я пришёл к выводу, что одновременно несколько компаний изобретают одни и те же велосипеды, считая, что это даёт им какую-то коммерческую выгоду. При этом открытость только декларируется, а исходники выкладывать никто не спешит, ибо “начальство не разрешает”. Одновременно с этим много людей реализует кастомные патчи и также не может их сделать общедоступныими из-за того, что заказчики им этого не позволяют.
По этим причинам я решил попробовать в силу своих возможностей проспонсировать разные полезные веб-разработчикам и мне лично мини-проекты, с условием, что их исходники будут доступны в инете с сохранением авторства их разработчиков.
ИМХО, это позволит сделать что-то полезное с минимумом багов, ибо эти мини-проекты подразумевают востребованность, а следовательно и баг-репорты. А самим разработчикам кроме морального удовлетворения получить полезный бэкграунд, влияющий на их ЗП.
Первый подобный опыт увенчался успехом и сейчас в основной ветке memcached-а добавился APPEND и PREPEND http://code.sixapart.com/trac/memcached/changeset/627 ( перловый клиент с APPEND и PREPEND пока доступен только здесь https://mdounin.ru/hg/Cache-Memcached/rev/f5cfb726ea65 , но скорее всего его тоже закомитят). Также исправлена работа по unix-сокету под FreeBSD http://code.sixapart.com/trac/memcached/changeset/624 . Всё это сделал Максим Дунин, за что ему огромное спасибо.
Вот несколько задач, которые ждут своей реализации и дадут небольшие полезности веб-разработчику:
- отдача nginx-ом из memcached-а сжатых ключиков. HTML хранить в memcached-е лучше сжатым и отдавать его браузеру также сжатым, если браузер может принять сжатый ответ и разархивированным, если браузер не хочет сжатые ответы. По статистике большиство браузеров и половина поисковых ботов хотят именно сжатый контент. Было бы логично хранить контент сжатым заранее. Кроме того сжатие более ресурсоёмко, чем разсжатие.
- доработка APPEND и PREPEND для более гибкой работы со списками. Значение хранимого значения ключика рассматривается как список и хочется добавлять в этот список строчки с в начало и конец, так, чтобы не было дублирования строчек в этом списке. В частном случае можно применять для удаления строчки из списка.
- не ожидающий ответа от memcached-а перловый клиент. Выполняя операцию, например, удаления ключика, мы не хотим ждать ответа от memcached, ибо нам не интересен . Поэтому соединение можно закрыть сразу после отправки команды memcached -у , а не ждать ответа.
- delete_multi() для memcached-а и перлового клиента.
- в nginx корректно устанавливать $upstream_response_time для ответов из memcached-а. Полезно для логирования $upstream_response_time в аксес-лог и последующего анализа залогированных значений.
Сайт с trac-ом и листом рассылки для этого проекта будет сделан при первой необходимости. Это дело 5-ти минут.
Если Вам интересно реализовать вышеописанное, то напишите пожалуйста мне об этом на аську 166233339 или мыло postmaster softsearch ru .
