Под языком я имею ввиду нормальный язык программирования -- ассемблер, C++, Java и т.д. На этих языках и можно написать это "все" :)
Другое дело, если языки ненормальные -- например, языки HTML-шаблонов без возможности алгоритмических вставок, или какие-нибудь чудовищные интерпретаторные языки для специфических предметных областей.
В Коммунивер.сервере есть все необходимые интерфейсы, позволяющие считать его "нормальным": ядро его прекрасно дополняется перловыми модулями. На данный момент запроектирован (и частично реализован ;) механизм пакетов -- можно будет взять кусок функциональности, состоящий из перлового кода, кода на языке шаблонов, куска онтологии на XML, и даже некоторых данных, и просто вставить его в действующих инстанс.
Согласен тем не менее, что если бы в этом списке составляющих пакета не было бы перла, то мое заявление про "любые языки" было бы голословным. Ведь мы же не все подряд торжественно называем "язык", да? ;)
В своем коментарии к вашему посту
я усомнился в том, что ЖЖ является приложением-убийцей Коммунивер.сети.
Усомнился на том основании, что ЖЖ и Коммунивер нацелены на разные применения.
Я и сейчас (после того, как вы поправили мое понимание того,
что есть Коммунивер.сеть) продолжаю так думать.
* * *
Отдельно возникла вторая тема --
"если б меня спросили, что нужно малым бизнесам для счастья":
Если б меня спросили, что нужно малым бизнесам для счастья,
то я сказал бы, что это должна быть вещь в духе Wiki,
но более развитая: с возможностями програмной автоматизации,
метаданными, темплейтингом, и т.п.
Естественно, функциональность ЖЖ на этой штуке может быть реализована,
но по-новому осмысленная.
Другой способ смотреть воспринимать такого зверя --
как реализацию лучших идей Lotus Notes, но в духе принципа KISS.
Я готов ответить за базар и попробовать объяснить, что я имел в виду.
Под "лучшими идеями Lotus Notes" я подразумеваю:
все, что можно, хранить не на локальной машине, а в сетевой среде
хранить в системе по возможности все -- контакты, почту, TODOs, ...
дать возможность сослаться на любую единицу хранения и из любого места
Первое ("интранетизация") кажется, на первый взгляд, банальностью.
На самом же деле, хотя принцип "работаем в сети" декларируется
везде, где только можно, существует масса технологических и, хмм, эргономических
ограничений, из-за которых мы продолжаем пользоваться "локальными" дисками.
Второй пункт ("храним в системе все") сопряжен с очевидной опасностью:
невозможно построить систему организации информации, которая одинаково хорошо
работала бы для всего многообразия информобъектов, и была при этом удобна
для пользователей с иногда диаметрально противоположными требованиями.
Моя позиция такова: да, построить идеальную систему невозможно,
но можно дать пользователям инструменты для построения
приемлемого рабочего окружения внутри системы, средствами системы
(посмотрите, сколькими способами пользователи Windows
используют тамошнюю файловую систему
для организации своих файлов).
Что касается третьего пункта, то ориентация на адресуемость отдельных информобъектов
кажется мне уже недостаточной. Фрагменты, дайте мне фрагменты!
Посмотрим теперь на семейство Wiki.
При абсолютном минимализме инструментальных средств, эти системы
позволяет обустраивать личное информационное пространство быстро
и, на мой вкус, довольно удобно.
Автоматически возникающие гиперссылки представляются мне отличной идеей,
развитие которой ведет в неизведаном еще, но воспринимаемом-мной-как-правильное направлении.
{это -- отдельная большая тема}
Именно эту идею я имел в виду, говоря о "духе Wiki".
Впрочем, Wiki присущи неискоренимые врожденные недостатки, такие как
слонность превращаться в помойку, примитивность механизма
автоматических ссылок (плата за простоту), уродливость внутреннего языка разметки.
В большинстве реализаций отсутствует грамотный механизм слияния изменений,
версионный контроль примитивен, а средства навигации
по временному измерению документов -- недостаточны.
* * *
Итак. С моей точки зрения, типовая система, с помощью которой
можно пытаться осчастливить малые бизнесы, должна пытаться собрать
под одну крышу основные виды рабочих данных, со-организовывать их,
предоставлять сотрудникам возможность обустраивать личное информационное
пространство (или получать уже обустроеное -- в качестве автоматизированого рабочего места).
Ключевым здесь является то, что уровень логической организации данных
приоткрыт для пользователей, а не спрятан полностью за специализированым GUI.
За этим (очень общим) описанием стоит пробная реализация.
Главный мой point таков: "оказывается", пользователи, обладающие высокой квалификацией
в какой-либо области (кадровики, менеджеры проектов)
могут быть партнерами разработчиков и внедренцев,
помогающими "выращивать" информационную систему.
1) Да, конечно, ЖЖ и Коммунивер.сервер нацелены на разные применения -- один является инструментом создания приложений, а другой готовым приложением. Но интересно пообсуждать некоторые фичи "готового приложения ЖЖ" как стандартные возможности в самых разных приложениях, которые можно ваять на Коммунивер.сервере. Кстати, дистрибутив Коммунивер.сервера поставляется с готовым "стандартным вебсайтом".
2) Про "дух Wiki" нужно разворачивать и разворачивать. Такое впечатление, что для вас сквозь Wiki проступает модель чего-то интересного, сильно затушеванного "неискоренимыми врожденными недостатками, такими как
слонность превращаться в помойку, примитивность механизма
автоматических ссылок (плата за простоту), уродливость внутреннего языка разметки.
В большинстве реализаций отсутствует грамотный механизм слияния изменений,
версионный контроль примитивен, а средства навигации
по временному измерению документов -- недостаточны".
Я думаю, что правильным действием было бы выписать черты лица этого "духа", вселившегося в Wiki, в виде некоторого перечисления -- имея перечисления в вышеотцитированном абзаце как образец (специально взял абзац, в котором перечислялись _спрятанные_ черты "идеала для малого бизнеса", а не те абзацы, где перечислялись удачи Wiki. В итоговом тексте нужны _все_ черты, в том числе и нереализованные ;)
Еще из моделей "сетевых сред" рекомендую глянуть на BrainEKP (http://www.thebrain.com), хотя интерфейс этот весьма и весьма специфичен. У меня у самого стоит на компьютере Personal Brain, и я над ним думаю... Еще рекомендую сходить на www.kurzweilAI.net в раздел Brain и поглядеть на тамошнюю организацию материалов -- это к вопросу об организации помоек.
Про помойки я вынес в общую ленту -- мысль пришла вдруг забавная...
3) Конечно, системы должны создаваться _вместе_ с пользователями, а не _для них_. Только вот идея shell мне кажется странной сразу по нескольким пунктам: а) концепция единых информационных корпоративных порталов предприятия сейчас развалилась, ибо большинство предприятий радостно начинают реализовывать несколько разных информационных порталов. Оказалось, так удобнее. б) такая среда будет, конечно, многопользовательской операционной системой. То есть нужно будет решить все те же вопросы, что решали авторы многопользовательских операционок ;) То есть что-то успеха в этом направлении пока не видно, хотя попыток было много :))) в) малым фирмам не столько интранет нужен, сколько маркетинг и сейлз, а также поддержка контактов вовне. Я бы предложил думать проще: фирмам нужны вебсайты, чтобы к ним прилипали клиенты. Ибо если нет вебсайта, к которому прилипает клиент, никакой интранет фирме не поможет. А уж в тот момент, когда вебсайт уже есть, можно потихоньку присоединять к нему другие внутрифирменные информационные системы (прямо по учебникам маркетинга -- приближая внутренние отделы фирмы, ведущие эти системы, непосредственно к клиентам фирмы). Поэтому "выращивать" нужно начинать с вебсайта, чтобы мысль о клиентах не потухла :) Даже business process reengineering рекомендует строить бизнес-процессы с клиентской стороны. Поэтому мысль идти к кадровикам и что-то для них "выращивать" меня пугает, ибо далеки кадровики от забот малой фирмы -- нафиг не нужно для 4-5 человек кадровой информационной системы ;) А малые бизнесы -- это от 1 до 25 человек для меня. Дальше организация бизнеса резко меняется, и меняются IT-задачи...
А уровень логической организации данных нужно, конечно, открывать. Вопрос только, не окажется ли логическая организация данных для каждого пользователя различна.