А с VoIP решениями от QTECH никто не сталкивался? Я просто в постоянном поиске хорошего VoIP-железа, а Dlink в этой области просто нереально унылое говно, да и вообще мало хороших производителей в этой области.
Продукцию Тольятти мы по-моему успешно проехали, по крайней мере в Сибири о ней не вспоминают при выборе авто.
А вот телекоммуникационное оборудование в нашей стране делать умеют, и это повод для радости. Впрочем, вспоминая свой ВУЗ, меня этот факт не удивляет.
Мне вот отмазка, что это мол пример, не канает. Зачем мне пример, если там все через задницу? Даже я, и то вижу, что это плохой код. А пафос, с которым статья преподнесена, усугубляет во сто крат.
Извините, я видимо не в теме, но про распределённость у memcached ничего не слышал. Из wikipedia:
Клиентская библиотека используя ключ данных вычисляет хэш и использует его для выбора соответствующего сервера. Ситуация сбоя сервера трактуется как промах кэша, что позволяет повышать отказоустойчивость комплекса за счет наращивания количества memcached серверов и возможности производить их горячую замену.
Если вы про эту распределённость, то можете втыкать этот сервер в один ряд с оригиналом — расширения, которые я сделал, совместимость не ломают.
Интерес прост — хочется иногда что-нибудь этакое сочинить. Ну и как вы могли заметить, я несколько расширил протокол. Если вы владеете python, то вам не составит труда вставить в сервер что-то свое.
Закоммитил на github изменения, еще раз спасибо за очень дельное замечание. Действительно очень часто встречается ситуация, когда хочется что-то слегка подменить в поведении используемой библиотеки, а потом приходится тащить за собой ее исправленный код, из-за того, что встроенной возможности не было, и пришлось библиотеку править.
Большое спасибо! Я это обязательно кстати поменяю.
С Cache, хмм, ну я просто не совсем понимаю как лучше тут поступить — один и тот же его экземпляр должен использоваться пачкой экземпляров MemcacheProtocol, хотя тут я думаю можно экземпляр в фабрику записать. Точно, это гибче, ушел делать: )
Да, если не помнить о косячной развязке com-порта. У меня никогда в жизни проблем, с кабелем выдернутым не было, и только у максикома наглухо сгорел весь блок управления, когда задели этот самый кабель.
Я не знаю что там с русскими шлюзами, я не такой рисковый парень, чтобы их брать, особенно перелицованные длинки, но Addpac то еще глюкалово, я 2 недели разрабам доказывали, что у них баг в SDP, который нормальный человек, разбирающийся в теме, сразу видит. И это шлюз, а про телефон, которым баловался в то же время, я вообще молчу.
А вы бы посмотрели на досуге чтобы оно под wine-ом запускалось, а? Ну понятно, портировать тяжело, но можно посмотреть на wine как на средство сделать облегченный реверанс в сторону модного нынче СПО.
Wine даст вам возможность продавать свое ПО не только под Linux, FreeBSD, но и под Mac.
Впрочем решение за вами, я так понимаю у вас сейчас горячая пора по выпуску релиза.
А вот телекоммуникационное оборудование в нашей стране делать умеют, и это повод для радости. Впрочем, вспоминая свой ВУЗ, меня этот факт не удивляет.
Если вы про эту распределённость, то можете втыкать этот сервер в один ряд с оригиналом — расширения, которые я сделал, совместимость не ломают.
Интерес прост — хочется иногда что-нибудь этакое сочинить. Ну и как вы могли заметить, я несколько расширил протокол. Если вы владеете python, то вам не составит труда вставить в сервер что-то свое.
С Cache, хмм, ну я просто не совсем понимаю как лучше тут поступить — один и тот же его экземпляр должен использоваться пачкой экземпляров MemcacheProtocol, хотя тут я думаю можно экземпляр в фабрику записать. Точно, это гибче, ушел делать: )
Wine даст вам возможность продавать свое ПО не только под Linux, FreeBSD, но и под Mac.
Впрочем решение за вами, я так понимаю у вас сейчас горячая пора по выпуску релиза.