Ну в общем тема обсуждалась и обсуждается — сопрограммы у нас сейчас на пике моды конечно, а асинхронностью бредят все, и особенно в приложении к Django: )
Посмотри вот тут — code.google.com/p/coev/source/browse/#hg/examples/django/hwcoev, хотя как я понимаю код в альфе. Я бы попробовал на самом деле влезть джанге в душу, то есть в глубины кода, но сейчас захвачен идеей попробовать собрать свой фреймворк с jinja и с pyrant-models, поверх вот этой вот моей обертки.
Хорошо, а когда вы передаете команду, которая заканчивается \n? Ведь сервер от ваc в этом случае ловит именно строку, неизвестной длины, оканчивающуюся \n. Я ведь не настаиваю, что это верное решение, просто оно используется.
Понятно, что бинарный протокол вообще эффективнее — команду одним байтом, длину ключа, длину данных, все отлично работает в tyrrant и многих других. И в этом вот случае серверу еще меньше работы: )
Просто удобно использовать в Twisted декоратор defer.inlineCallbacks, а он предполагает использование yield. Ну и мне сомнительно, чтобы можно было написать так — yield db['kuku']='data', да и колбек тут тоже повесить некуда: ) То есть неблокирующие операции имеют свою цену в некотором снижении удобства, но от этого пока никуда не деться.
Потому и api просто так не перельется — из-за вот таких вот заморочек.
Я хочу собрать фреймворк полностью, поэтому буду думать, как сделать лучше и удобнее.
Сейчас сделал базу — без pythonic/dict like. Потому что мне не совсем прозрачно, как через yield делать выборку из словаря: ) Поэтому я думаю, что dict like я оторву. Не такая уж это великая сложность вместо []= написать .set().
Знаете, я наверное перепишу pyrant и сделаю tx-pyrant. Просто если переписаться на твистед, то с обычными скриптами там делать уже нечего — надо обязательно уже работать только в рамках твистед. Будет ветка: )
А вот по логике втыкаемой, тут я не очень понимаю — это получается REST прослойка между сервером tyrrant и конечным клиентом? Ну на твистед это легко достаточно сделать. Просто надо всегда помнить, что мы работает в одном потоке, и тяжелые обработки надо скидывать в другие потоки.
Это уже не круто: ) — habrahabr.ru/blogs/python/78114/
Про потоки вы очень верно заметили, интересно было бы на эрланг реализацию посмотреть — memcache кластер малой кровью.
HTTP это запрос, ответ, закрыли сокет. Это время — лучше протокол с постоянным соединением, как и поступают с memcache зачастую. Ну а уж разбор строк это действительно медленная операция.
А я так и не понял — кто автор? Martin Conte Mac Donell, или вы?
Я бы привязал это дело к twisted наверное. Схемы URL от джанго + pyrant + twisted + jinja + чего-нибудь для форм, и вышел бы славный, очень производительный, фреймворк.
Почему twisted, а не пилонсы или торнадо? Потому что twisted это не только HTTP, а взаимодействовать надо зачастую с разными протоколами, да и нравится мне возможность гибко лавировать между использованием генераторного стиля и макаронно-колбечного. В случае с колбеками можно породить независимый процесс обработки какой-нибудь.
Если я администратор, и моя сеть лежит, то это я позвоню начальнику, и попрошу помочь мне получить доступ к телу как можно скорее — охрану предупредить и тп.
А как по вашему устроен интернет? То есть у интернета имеется в центре этакий мега маршрутизатор, через который всё проходит? А где центр?
На самом деле интернет скорее ячеистый — есть ячейки, сеть отдельных провайдерских сетей, внутри которых ходят протоколы маршрутизации семейства IGP, а между собой сети общаются посредством BGP — протокол граничного шлюза. Проблема в том, что полная таблица BGP уже имеет немаленький объем, и в этой ситуации BGP совершенно не подойдет. Да и вообще — как через атлантику ходить будем? Кто будет за обслуживание кабеля платить? Как Google будет доставлять контент до нас? Обложится кучей точек доступа? Хотя тут конечно есть зерно — рекламодатели могут давать деньги на поддержку канал доставки рекламы, но как вы понимаете, им совершенно неинтересна доставка до вас торрент трафика, или свежих обновлений на ОС.
То есть с протоколом то проблем не будет, математика у нас развита и алгоритм родят, если еще нет, но вот с магистральными каналами как быть, вопрос.
Как я понял ключевое это соединение точек доступа без подключения их всех в проводную сеть — можно развернуть сеть, достаточно чтобы точки друг друга видели. Это у Cisco заявлено, и это точно есть.
Быть может я не так понял суть MESH?
Посмотри вот тут — code.google.com/p/coev/source/browse/#hg/examples/django/hwcoev, хотя как я понимаю код в альфе. Я бы попробовал на самом деле влезть джанге в душу, то есть в глубины кода, но сейчас захвачен идеей попробовать собрать свой фреймворк с jinja и с pyrant-models, поверх вот этой вот моей обертки.
Понятно, что бинарный протокол вообще эффективнее — команду одним байтом, длину ключа, длину данных, все отлично работает в tyrrant и многих других. И в этом вот случае серверу еще меньше работы: )
Потому и api просто так не перельется — из-за вот таких вот заморочек.
Я хочу собрать фреймворк полностью, поэтому буду думать, как сделать лучше и удобнее.
github.com/Deepwalker/tx-tokyo
Сейчас сделал базу — без pythonic/dict like. Потому что мне не совсем прозрачно, как через yield делать выборку из словаря: ) Поэтому я думаю, что dict like я оторву. Не такая уж это великая сложность вместо []= написать .set().
А вот по логике втыкаемой, тут я не очень понимаю — это получается REST прослойка между сервером tyrrant и конечным клиентом? Ну на твистед это легко достаточно сделать. Просто надо всегда помнить, что мы работает в одном потоке, и тяжелые обработки надо скидывать в другие потоки.
Про потоки вы очень верно заметили, интересно было бы на эрланг реализацию посмотреть — memcache кластер малой кровью.
Я бы привязал это дело к twisted наверное. Схемы URL от джанго + pyrant + twisted + jinja + чего-нибудь для форм, и вышел бы славный, очень производительный, фреймворк.
Почему twisted, а не пилонсы или торнадо? Потому что twisted это не только HTTP, а взаимодействовать надо зачастую с разными протоколами, да и нравится мне возможность гибко лавировать между использованием генераторного стиля и макаронно-колбечного. В случае с колбеками можно породить независимый процесс обработки какой-нибудь.
На самом деле интернет скорее ячеистый — есть ячейки, сеть отдельных провайдерских сетей, внутри которых ходят протоколы маршрутизации семейства IGP, а между собой сети общаются посредством BGP — протокол граничного шлюза. Проблема в том, что полная таблица BGP уже имеет немаленький объем, и в этой ситуации BGP совершенно не подойдет. Да и вообще — как через атлантику ходить будем? Кто будет за обслуживание кабеля платить? Как Google будет доставлять контент до нас? Обложится кучей точек доступа? Хотя тут конечно есть зерно — рекламодатели могут давать деньги на поддержку канал доставки рекламы, но как вы понимаете, им совершенно неинтересна доставка до вас торрент трафика, или свежих обновлений на ОС.
То есть с протоколом то проблем не будет, математика у нас развита и алгоритм родят, если еще нет, но вот с магистральными каналами как быть, вопрос.
Быть может я не так понял суть MESH?