Обсуждение

нпж - so early 90s! концептуально какая-то каша, свалка велосипедных рулей.

Согласен, согласен. Но, как и крайне концептуально кашеобразный язык Си -- может неожиданно победить и пойти в массы, потому что вся эта... гм... эклектичность может быть крайне прагматична в своих осколках. Проект как раз и интересен своей прагматической направленностью, а не "разворачиванием одной высококонцептуальной идеи" с пофигистским отношением к пользователям. Я бесполезных "концептуальных проектов" много навидался. Все слишком красивое часто не рабочее, а только prove of concept. Не будем даже спорить -- просто поглядим на этот проект через пару лет.

А потом подождем 2 года и посчитаем число узлов и юзеров НПЖ и число узлов и юзеров вашей системки ;)

ага, посчитаем-посчитаем число юзеров нашей системищи

а где на коммунивер поглядеть моан?

AFAIK, от размера БД в НПЖ сейчас скорость практически не зависит. Сильно зависит от наличия PHP-акселератора и от навороченности "шкуры".

А можете конкретизировать претензии?

Дистрибутив можно взять на www.communiware.ru

Как я понимаю, "шкура" у вас -- это то, что у нас называется "шаблоны". В какой-то момент программеры с удивлением обнаружили, что только один набор шаблонов -- "базовые шаблоны" занимает по объему текстов что-то вполне сравнимое с объемом кода самого движка. Ничего удивительного. Для этого вот и предназначена у нас "компиляция шаблонов". Через некоторое время вы будете думать о "компиляции шкуры" ;) А скорость, не зависящая от размеров базы -- это следствие жесткой типизации. Поелику у нас там внутре какое-никакое представление знаний, медленность в Коммунивер.сервер заложена архитектурно. У нас есть написанная уже резидентная база, которая должна дать *100 по скорости, но опенсорс проекты развиваются меееедленно ;) По-хорошему, конечно, все это нужно в какой-нибудь момент бросать и переписывать "с нуля" -- и вам, и нам. Но не сейчас, конечно.

простите за оффтоп, а можно поинтересоваться - что Вы имеете ввиду под отсутствием жёсткой типизации? если я правильно понимаю, в аспекте субд речь идет о том, что ядро системы составляет интерфейс работы с динамически формируемой мета-моделью. и в данном случае говоря о "компиляции" мы говорим о том, что гибкость мета-модели - хорошо, а в возможности динамической "перекомпиляции" кода/данных из мета-модели в "жесткие типы" - ещё лучше?

Нет, в контексте базы данных принято больше говорить о мемоизации (запоминании результатов частичных вычислений доступов, и вообще -- о предварительных частичных вычислениях доступов к базе), а "компиляция" -- это к интерфейсным алгоритмам, а не к мета-данным. Фактически, Коммунивер.сервер представляет собой "нереляционную базу данных" (сейчас смоделированную на реляционной) и интерфейсные (ввод-вывод с/на экран содержимого БД) процедуры. Вот эти процедуры компилируются, а БД честно уже есть нереляционная. Теперь нужно сделать два шага: выпустить версию с компиляцией интерфейсных процедур, и затем выпустить версию с "честной" нереляционной БД. В одном случае честная компиляция алгоритмического языка (хотя и не вполне процедурного, заметим), а во втором случае оптимизация исполнения запросов.

>>частичных вычислений доступов нет Вы говорите просто о кэшировании, а я имел ввиду не это - меня интересовал именно вопрос мета-данных. я попробую вкратце пояснить, о чем я. пусть мы говорим о некотором приложении, произвольном, хранилищем данных для которого является честная реляционная субд. если мы говорим о произвольном приложении, то есть о произвольной мета-модели, и поскольку традиционная субд не умеет существовать в режиме динамического изменения своей структуры - у нас есть некоторые проблемы. и есть (совсем грубо) два основных пути организовать хранение данных: традиционно, жёстко синхронизировать данные и код (новый атрубут сущности модели -> атрибут таблицы), или как-то менее жестко отобразить в реляционную модель произвольно меняемую модель данных (например: новый атрибут сущности в модели -> новый кортеж в "описательной" таблице). и мне показалось, что когда Вы говорили про "типизацию", Вы имели ввиду именно первый случай, и это дало мне повод считать, что коммунивер устроен как-то принципиально отлично от традиционного подхода. к сожалению, пока я не очень понимаю, в каким именно ключе коммунивер организует "представление знаний" - от того и задаю вопросы :) - но интуитивно мне кажется, что проблемы с производительностью должны быть не в том, какие временные задержки мы получаем из-за того, что шаблоны внешних интерфейсов "нескомпилированы", а как раз в принципе этого самого "моделирования нереляционной базы на основе реляционной". то есть насколько я понимаю, речь идет об "отображении" некоторой абстрактной модели в честную реляционную и инкапсуляции обычных запросов к субд в ядре коммунивера - что-то довольно близкое к object/relational mapping. насколько я могу судить по опыту это довольно сложная около-теоретическая область, существуют ли какие-то публикации - Ваши или Ваших коллег - на эту тему? просто этим вопросом интересуюсь довольно давно, но к сожалению, я не смог найти развернутого описания того, как это решено в коммунивере, а ряд жалоб на скорость работы от знакомых давал определенную пищу для размышлений...

претензии?

Скорее моменты, которые, по вашему мнению, превращают суп в кашу.

"каша, свалка". Что имеется в виду?

пасибы +) пороюсь

Смесь контрольного и презентационного уровней. У меня создалось ощущение, что дизайн системы был сделан не снизу вверх, а сверху вниз, а потом дизайнеры вспомнили, что есть такая вещь как MVC.

см. мой другой ответ в этой ветви

дизайн это не тот параметр НПЖ по которому его уже пора оценивать То что вы видите, зайдя на http://npj.ru - первый вариант оформления, он же шкура minikui, сделанный для того чтобы можно было посмотреть на максимум функциональности. Для сравнения - шкура criba: http://www.npj.ru/lance А вообще, работа над дизайном идет - и он (дизайн) планируется разным в зависимости от парадигмы использования.

Или вы имели ввиду проектирование системы?