Сообщение от Kolyaj
|
Зачем вам какой-то фреймворк? Для взаимодействия с CouchDB достаточно любого HTTP-клиента, коих полно как в PHP, так и в node.js имеется.
Ещё непонятно, как связан CouchApp и SpiderMonkey. Сам CouchApp на чём написан?
|
|
Цитата:
|
CouchDB можно рассматривать как сервер веб-приложений; для реализации этой идеи в CouchDB встроен производительный веб-сервер, а программный код, как и данные, сохраняется в той же базе данных. Для автоматизации работы с приложениями CouchDB используется утилита CouchApp.
http://ru.wikipedia.org/wiki/CouchDB
|
По пунктам:
PHP и иже с ним - 3d-party. Зачем преумножать сущности, если CouchDB может работать без лишних посредников и сама является http-сервером?
CouchApp - это фреймворк данный от разработчика и интегрированный в работу CouchDb, позволяющий участвовать в формировании ответов от сервера и их трансформации прозрачно для клиента. То есть то, что мы получаем по http, когда нам "достаточно любого HTTP-клиента" - уже прошло на ранней стадии через CouchApp (если это предусмотрено архитектурой серверной части приложения).
SpiderMonkey - движок JS использованный в CouchDB для запуска JS-кода. Он обслуживает как сам код map/reduce функций в базе, если они написаны на JS, так и дополнения CouchApp.
Всё это в высшей степени прекрасно ровно до того момента, когда появляется необходимость тонкой настройки уровней доступа к документам в базе, который невозможно отдать на откуп клиенту (по принципу "на тебе ключ от сейфа, возьми, сколько там тебе надо денег, но ни копейкой больше"). Конечно, открытые нараспашку базы "делают мир лучше", как любит повторять Крис. Но мир отнюдь не делает того же с открытыми базами.
Управление доступом в CouchDB реализовано на уровне баз. То есть просто так нельзя запретить клиенту получить полное содержимое базы и всех полей документов, если у него есть доступ на базу. Либо можно читать всё, либо ничего. Мы ищем наименее затратное средство реализации разграничений доступа в плане ресурсов сервера и команды разработчиков. И любой посредник в лице PHP, Python'а и прочих - не лучшее решение в данном случае, лишающее всех прелестей прямого доступа к базе по HTTP.
Впрочем, вариант посредника мы тоже рассматриваем, если его удастся сделать минималистичным и "незаметным", но пока что этот вариант оставлен как крайнее решение, при невозможности найти другие.