Абсолютно Открытая Система

Ладно, вот идея

Абсолютно Открытая Система
Делается на Yukon. Все документы хранятся в виде XML. Ядро умеет показывать колонки, доп колонки, а также на полную работают все наши навороты с фильтрами, группировками и прочее, благо Xquery есть

Когда кликаешь на документ, то запускается внешний EXE. Поэтому все документы клиента (накладные, платежки и пр).могут быть написаны им самим.

Ядро же работает с ЛЮБЫМИ документами. Идеально, например, для документооборота.

Если нужен учет документов, то есть склад, бюджеторование и др, то надо описать схему и сказать где в складской операции склады откуда, куда, дата итд.

При это в Абсолютно Открытой Система ядро как раз является закрытым (ENCRYPTED), а вот документы пишите какие хотите

Forums: 

Изображение пользователя ipanshin.

А чем отличаются dll and exe?

А чем отличаются dll and exe? Чтото это мне все напоминает.
А почему только на юконе? Да хранение доков в xml.
А exe хранятся в БД?
А как по поводу запуска несанкционированного экзешника?
Разве xml - это удобная форма хранения? Удобная форма передачи-Да.
Разве надо шифровать ядро?

Придем к куче экзешников a-la exe hipe.:)

Абсолютно Открытая

Абсолютно Открытая Система
Делается на Yukon. Все документы хранятся в виде XML.

Что-то у меня сомнения сразу возникают по поводу скорости поиска документов.
Получается если я хочу документы с заданным атрибутом найти, то ВСЕ документы надо пропускать через Parser.
Мне кажется, что с хранением в XML ты погарячился.

Предлагаю так, пользователь кликает на документ, ядро его упаковывает в XML, добавляет туда информацию о том, какой модуль (тип модуля м.б. любой - exe, dll, VBScript, JavaScritp и т.д.) работает с данным классом и отправляет некоторому брокеру классов. Тот принимает XML, и передает его указаному модулю. Модуль завершив работу с документом отдает его брокеру, тот посылает его ядру. Ядро раскладывает документ по таблицам хранения.
Описание классов задается в виде ХМL шаблона.

Что-то у меня сомн

Что-то у меня сомнения сразу возникают по поводу скорости поиска документов.
Получается если я хочу документы с заданным атрибутом найти, то ВСЕ документы надо пропускать через Parser.

Так
Срочно читайть мою статью о Yukon
Во первых XML в Yukon хранится вовсе не в виде строки а во внуреннем формате занимая в 2-3 раза меньше чем сама строка
Во вторых, он индексируется (CREATE XML INDEX ...) и поиск в нем очень эффективен

Наконец, данная система может

Наконец, данная система может иметь универсальный шлюз для приема ЛЮЫХ документов - WEB service, пишется на YUKON несколько строк. Вот и офис филиал....

Если не заморачиваться учетами, то система может быть вообще распределенной

Во первых XML в Yu

Во первых XML в Yukon хранится вовсе не в виде строки а во внуреннем формате занимая в 2-3 раза меньше чем сама строка
Во вторых, он индексируется (CREATE XML INDEX ...) и поиск в нем очень эффективен

Сколько занимает поиск документов с конкретным значением tag в базе из 100 000 документов?
Какой объем при этом занимают индексы?
На сколько хуже поиск, если индекс на tag не создан?

(Возможно все это есть в статье, просто я ее пока не видел).

IMHO, XML очень хорошо для обмена данными, а вот для хранения ... очень сомневаюсь.

Изображение пользователя ipanshin.

Что-то у меня сомн

Что-то у меня сомнения сразу возникают по поводу скорости поиска документов.

Да сомнительно чтобы парсинг был быстрее.

Т.е. предлагается следующая система

IE,...,Ie <-->WEB services<--|-->DB<--|-->nexus<--->exe/dll

А может лучше просто убрать нексус клиента и сделать

IE,...,Ie <-->WEB services<--|-->DB<--|-->WEB services<-->IE,...,Ie

И перейти на asp.net или аналогичное. В этом решении скрытая трехзвенка.

Изображение пользователя Serguei_Tarassov.

А в статье можно п

А в статье можно пользоваться тегами CODE ?

В статье пользуй чистый хтмл, т.е. тег "pre".