Алексей Черемисин: но не использовать же amqp для чата. Есть намного более удачные реализации.
В своем ответе я же хотел акцентировать внимание на то что это геморой, хоть и не такой смертельный. Готовых реализаций хватает, как отдельно I/O серверов (решает проблемы по нагрузке в плане обработки соединений и т.д.), так и чатиков. Проблему аунтефикации и авторизации всеравно решать придется.
*mq нужны для реализации шины данных между частями приложений, а не для чатика. rabbitmq вообще не подходит под это. Да и на сокетах написать чатик не проблема.
brainflow: ну вам по сути нужно как-то синтаксис шаблонов сделать:
*{1, 2}my
описывает "любой символ в количество от одного до двух
И это дело можно скомпилить в /.{1, 2}/ вообще без проблем. То есть мы сначала экранируем все что можно а потом производим подмену.
Ну то есть я предлагаю взять за основу регулярки и упростить их. К сожалению готовых реализаций врят-ли найдется ибо все что я знаю использует синтаксис все тех же регулярок. И я считаю что это лучше чем придумывать свою шляпу так как по сути у вас выйдет то же самое, но есть риск что модераторы уже знают минимально регулярки или смогут их освоить и сделать этот навык полезным для себя.
Sergey Romanov: а какой в этом смысл? Отказаться от директив, встроенного датабиндинга (во всяком случае для view) и полностью заменить этот стэк на накаут? В чем проблема так сделать с Ember? Юзают же reactjs и с тем и с тем.
Sergey Romanov: backbone не фреймворк, выкидываем его из списка. Вы можете использовать коллекции бэкбоновские в angular/ember приложениях и все будет хорошо.
Концепция толстых клиентов подразумивает что на клиенте происходит большая часть всех штуковин. Рендринг, бизнес логика и т.д. То есть любой нормальный SPA. А сервер нужен для персиста данных. В этом ключе и Angular и Ember для толстых клиентов.
И что вы имели в виду под агностичностью ангуляра? То что он не требует зависимостей? Пф...
fryette: да, можете. $resource это высокоуровневая обертка над $http для работы с HTTP ресурсами (читать про REST и т.д.). Тогда документацию по $resource.
Александр Аксентьев: Ratchet не умеет клиент. Я не так давно ресерчил библиотеки для этих целей - то что я скинул единственное живое и рабочее решение.
Snort: у вас выходит зависимость по данным с подзапросом, в этом случае MySQL не будет особо пытаться это дело оптимизировать. С JOIN-нами хотя бы есть варианты и прогнозируются они лучше.
gurinderu: я не вижу смысла заводить спор с Java разработчиком по поводу того что c# лучше. Оба языка не являются моими основными, писал и на том и на том. Считайте это моим личным мнением.
В своем ответе я же хотел акцентировать внимание на то что это геморой, хоть и не такой смертельный. Готовых реализаций хватает, как отдельно I/O серверов (решает проблемы по нагрузке в плане обработки соединений и т.д.), так и чатиков. Проблему аунтефикации и авторизации всеравно решать придется.