Проектирование и разработка СУБЗ Сообщение DenisKoronchik » 21 окт 2011, 20:04 СУБЗ - система управления базами знаний На текущий момент необходимо решить следующие проблемы: поддержка юникода (возможно окажется лишней, но надо предусмотреть). Лишней может быть по причине того, что сама СУБЗ не будет оперировать строками, она будет возвращать данные в бинарном виде, а там уже клиент работающий с ней сам представляет их в нужном виде. Это представление определяется по семантической окрестности sc-ссылки из которой взяты данные реализовать интерфейс потока данных (аналог QIODevice (http://doc.qt.nokia.com/latest/qiodevice.html)). Этот интерфейс будет использоваться при работе с содержимыми для чтения и записи данных определиться с основными интерфейсами, через которые будет осуществляться доступ к хранилищу sc-кода (наработки (http://ostis.svn.sourceforge.net/viewvc/ostis/trunk/ui/sui/sui/interfaces/ScMemory.h?revision=1061&view=markup)) определиться с набором необходимых функций более высокого уровня (наработки (http://ostis.svn.sourceforge.net/viewvc/ostis/trunk/ui/sui/sui/interfaces/ScHelper.h?revision=1061&view=markup)) определиться с тем каким образом будут подключаться sc-агенты реализованные на различных языках (скорее всего целесообразно использовать плагины) все интерфейсы надо проектировать так, чтобы потом их легко можно было бы обернуть под более высокоуровневые языки программирования типа erlang, для более простой реализации под web Вот такие пока проблемы. После того как все будет уточнено, а тут далеко не полный список, можно будет говорить о том как это реализовывать. DenisKoronchik Сообщение ZhitkoVA » 22 окт 2011, 15:07 DenisKoronchik писал(а):[*] определиться с основными интерфейсами, через которые будет осуществляться доступ к хранилищу sc-кода (наработки) Все таки предлагаю вернуть на самый нижний уровень интерфейса функции типа search_f_a_f и пр. (к использованию необязательны) но хороши т.к. сохраниться связь и аналогия с SCP, что позволит показать что и в SCP и во внешних языках мы ведем речь о одних и тех же вещах. Важно так же и удобство перехода от CSP к реализациям на других языках (даже автоматические). Остальные функции более высокого уровня нужны для более удобной и быстрой разработке. ZhitkoVA Сообщение DenisKoronchik » 22 окт 2011, 21:44 не вопрос, их можно вернуть, но не имеет смысла делать это на самом нижнем уровне, на нижнем уровне лучше сделать общую функцию, так как большое количество функций в интерфейсах нижнего уровня - это проблемы и лишние заморочки при реализации. Лучше их вынести в класс, который используя самый нижний уровень будет реализовывать их. А вообще стоит подумать и посмотреть, нужны ли они вообще? Ведь в scp их нет. В scp мы как раз таки и используем свободную форму, а шаблон подбирается автоматом: Код: выделить все searchElStr3([ 1_: fixed_: mystat, 2_: assign_: const_: pos_: arc, 3_: fixed_: stat ],exit) Они есть лишь в текущей реализации памяти, на которую точно не надо ориентироваться. DenisKoronchik Сообщение admin » 22 окт 2011, 22:51 DenisKoronchik писал(а): поддержка юникода (возможно окажется лишней, но надо предусмотреть). Лишней может быть по причине того, что сама СУБЗ не будет оперировать строками, она будет возвращать данные в бинарном виде, а там уже клиент работающий с ней сам представляет их в нужном виде. Это представление определяется по семантической окрестности sc-ссылки из которой взяты данные реализовать интерфейс потока данных (аналог QIODevice). Этот интерфейс будет использоваться при работе с содержимыми для чтения и записи данных Касаемо проблемы юникода, по приведённым интерфейсом видно, что часть методов работы с памятью содержит строковые параметры поэтому встает вопрос при независящей от Qt как будет реализована операция сравнения строк без юникода? Ведь во всех СУБД сравнение строк тесно связана с кодировкой. В MySQL такая опция явно прописывается для каждой таблицы и базы, чтобы указать в какой кодировке будет происходить сравнение строк. Да же в том случае, если вся информация хранится в бинарном представлении, с поиском вопрос о кодировке текстовых содержимых элементов просматривается явно. Неужели разработчикам операций необходимо будет каждый раз операции сравнения строк реализовывать самостоятельно? Вопрос по потокам данных, чем конкретно не устраивают механизмы работы с потоками данных, которые имеются в С и С++, что необходима реализация интерфейса типа QIODevice? admin Сообщение DenisKoronchik » 23 окт 2011, 01:02 Юникод возможно вообще не нужен, просто СУБЗ будет отдавать через IODevice данные, а сам клиент будет с ними работать. Поиск содержимого идет по хеш суме. Можно использовать класс (http://ogre.svn.sourceforge.net/viewvc/ogre/trunk/OgreMain/include/OgreUTFString.h?revision=9952&view=markup) он поддерживает работу с UTF-8, UTF-16, UTF-32. Но опять же здесь будет достаточно std::string, ибо это просто контейнер, который может и utf-8 хранить и utf-16 и так далее. Все равно его содержимое читается из содержимого узла и пишется туда в бинарном виде. В данном случае СУБЗ даже не надо это знать, в отличие от mysql, ибо мы просто оперируем байтами, не ведая о том, что ими представлено. Что касается потоков, то нужен абстрактный интерфейс, который одинаково будет работать, как с файлами на файловой системе, как с файлами по сетевым протоколам, как с памятью. Грубо говоря, сама реализация памяти нам будет отдавать такой интерфейс, а как в ней храниться файл нам не важно, мы работаем с ними не зная о том как они физически хранятся (речь про содержимые). Нам не надо данные загружать в память, просто читаем, пишем или делаем то что нам надо. DenisKoronchik Сообщение admin » 23 окт 2011, 10:54 DenisKoronchik писал(а):Юникод возможно вообще не нужен, просто СУБЗ будет отдавать через IODevice данные, а сам клиент будет с ними работать. Поиск содержимого идет по хеш суме. Можно использовать класс (http://ogre.svn.sourceforge.net/viewvc/ogre/trunk/OgreMain/include/OgreUTFString.h?revision=9952&view=markup) он поддерживает работу с UTF-8, UTF-16, UTF-32. Но опять же здесь будет достаточно std::string, ибо это просто контейнер, который может и utf-8 хранить и utf-16 и так далее. Все равно его содержимое читается из содержимого узла и пишется туда в бинарном виде. В данном случае СУБЗ даже не надо это знать, в отличие от mysql, ибо мы просто оперируем байтами, не ведая о том, что ими представлено. Что касается потоков, то нужен абстрактный интерфейс, который одинаково будет работать, как с файлами на файловой системе, как с файлами по сетевым протоколам, как с памятью. Грубо говоря, сама реализация памяти нам будет отдавать такой интерфейс, а как в ней храниться файл нам не важно, мы работаем с ними не зная о том как они физически хранятся (речь про содержимые). Нам не надо данные загружать в память, просто читаем, пишем или делаем то что нам надо. Строковые данные в зависимости от кодировки в бинарном виде представляются по разному, mysql другие тоже оперируют байтами не зная, что в них представлено, но у них еще есть метаинформация, которая позволяет пользователю знать в какой кодировке или как эти данные представлены. И эта же метаинформации используется при реализации операций поиска в самой СУБД. На вопрос ответа не получил, я спросил как планируется реализовать без поддержки и указания кодировок операцию сравнения сравнения 2-x строк? Опять же на второй вопрос не получил ответа. Мне понятна необходимость интерфейса для работы с потоками ввода/вывода, но непонятно чем не устраивают механизмы С++ или С для работы с такими потоками, почему нельзя взять их за основу? admin Сообщение DenisKoronchik » 23 окт 2011, 12:37 В вопросе касающемся строк, не могу придумать задачу, где СУБЗ понадобиться знать о способе их кодирования и сравнении. Может приведете? Что касается потоков, если черь идет о std::istream, std::ifstream и подобным, то они имеют одинаковый интерфейс, но в основе их насколько я понимаю не лежит общий класс или интерфейс, а сама суть IODevice заключается именно в этом, что он абстрагирует нас, вот сделаем интерфейс IODevice, а реализация для файлов может основываться на ifstream, для буферов в памяти на istream и так далее. В документации Qt написано четко зачем это нужно: Код: выделить все QIODevice provides both a common implementation and an abstract interface for devices that support reading and writing of blocks of data, such as QFile, QBuffer and QTcpSocket. QIODevice is abstract and can not be instantiated, but it is common to use the interface it defines to provide device-independent I/O features. For example, Qt's XML classes operate on a QIODevice pointer, allowing them to be used with various devices (such as files and buffers). DenisKoronchik Сообщение admin » 23 окт 2011, 13:50 DenisKoronchik писал(а):В вопросе касающемся строк, не могу придумать задачу, где СУБЗ понадобиться знать о способе их кодирования и сравнении. Может приведете? Например, операция склейки двух элементов на основании того, что их идентификаторы одинаковы(см. презентации Голенкова и Ивашенко). Для того, чтобы их склеить необходимо убедится, что идентификаторы одинаковы. Эта задача решается только при условии, что будет корректная операция сравнения строк. DenisKoronchik писал(а):Что касается потоков, если черь идет о std::istream, std::ifstream и подобным, то они имеют одинаковый интерфейс, но в основе их насколько я понимаю не лежит общий класс или интерфейс, а сама суть IODevice заключается именно в этом, что он абстрагирует нас, вот сделаем интерфейс IODevice, а реализация для файлов может основываться на ifstream, для буферов в памяти на istream и так далее. В документации Qt написано четко зачем это нужно: Код: выделить все QIODevice provides both a common implementation and an abstract interface for devices that support reading and writing of blocks of data, such as QFile, QBuffer and QTcpSocket. QIODevice is abstract and can not be instantiated, but it is common to use the interface it defines to provide device-independent I/O features. For example, Qt's XML classes operate on a QIODevice pointer, allowing them to be used with various devices (such as files and buffers). Тоже самое в классах С++ ios_base (http://www.cplusplus.com/reference/iostream/ios_base/). Код: выделить все Base class with type-independent members for the standard stream classes ios_base->ios The ios_base class is designed to be a base class for all of the hierarchy of stream classes, describing the most basic part of a stream, which is common to all stream objects. Therefore, it is not designed to be directly instantiated into objects. Both the ios_base class and its derived class ios define the members of every stream that are independent of whether the stream object is an input or an output stream. Among these, ios_base describes the members that are independent of the template parameters (i.e. the character type and traits), while ios describes the members that depend on them. Мне непонятно зацикливание на классах Qt, которые должны обеспечить платформенную независимость библиотеки уровня операционной системы. По сути необходим только интерфейс передачи бинарных данных на уровне файл-оперативная память, файл-файл и оперативная память - оперативная память, совместимый с большинством С++ или С платформ. Про интерфейс для удалённого подключения отдельный вопрос, в разных СУБД это решается по разному, в зависимости от конкретного языка и с учетом платформ для драйверов к СУБД типа JDBC, ODBC, OLE DB, BDE. admin Сообщение DenisKoronchik » 23 окт 2011, 14:18 Зациклливания нет, есть лишь пример, того что нужно по функционалу, если в ios_base есть весть такой функционал, то отлично. Что касается сравнения, то нам и не надо знать в содержимом строка или нет, мы просто сравниваем по хеш сумме, для одинаковых строк с одной кодировкой она совпадет. Вопрос о том в какой кодировке лежат строки в содержимых принимается разработчиками системы, которая использует СУБЗ и все. Кроме того, над каждым содержимым настраивается еще и мета информация, которая явно указывает кодировку. Но опять же повторюсь, что для склейке нам надо найти по содержимому узел (это сравнение хеш суммы), а потом от узла по отношению идентификация выйти на объект, и все. При этом не обязательно знать что храниться в содержимом строка, изображение, звук и так далее и в каком виде. Вид определяется договоренностью в внутри между разработчиками системы, а не в СУБЗ. Иначе последней придется работать со всеми возможными кодировками, что очень накладно и даже не имеет смысла. Приведу пример: Разработчики системы с помощью инструментов собрали БЗ из исходников, при этом явно сказали, что используют UTF-8. В базу знаний весь текст лег именно в этой кодировке. Дальше когда им надо найти по идентификатору элемент, они ищут содержимое, на вход подавая бинарные данные, которые сожержат строку в UTF-8, по хеш сумме находятся все содержимые (совпадение по всем байтам), и все. При этом сама СУБЗ вообще не знает о том, в каком виде строки используются. Если разработчики используют несколько кодировок, то им приходиться это учитывать. Также как и в mysql создается БД (в нашем случае БЗ) в которой кодировка заранее предопределена разработчиками системы, только в нашем случае СУБЗ и понятия не имеет какая используется, ей это собственно и не нужно. Она просто как проводник по сетевым структурам. DenisKoronchik Сообщение admin » 23 окт 2011, 15:33 Ну хорошо ! Установили, что кодировка должны быть и что разработчики БЗ должны прийти к соглашению какую кодировку они будут использовать. А какую кодировку будет использовать программист, который работает с обсуждаемым фреймворком? Какая кодировка будет внутренней? Я предлагаю UTF-8. Есть другие варианты? По поводу потокового ввода/вывода, решение на базе iso_base кажется мне наиболее приемлимым, так как для большинства инструментов для разработок оберток под другие языки решения для STL и производны классов от него уже включили в свою реализацию, разработка своего интерфейса для потока ввода вывода приведет к тому, что нам придется дорабатывать фреймворк для того, чтобы он портировался на другой язык возможно в ущерб самому фреймворку. По поводу существующей наработки вопрос такой: почему бы не перенести разработанные для python версии механизмы работы с операциями на текущую версию соответственно с доработкой, если таковая выявлена в процессе использования python-версии такого фреймворка? admin Сообщение DenisKoronchik » 23 окт 2011, 18:11 Ну в наработках уже есть работа с операциями и выделен интерфейс для них, там всего две функции проверка условия выполнения и собственно само выполнение (http://ostis.svn.sourceforge.net/viewvc ... iew=markup) (http://ostis.svn.sourceforge.net/viewvc/ostis/trunk/ui/sui/sui/kpm/suioperation.h?revision=1063&view=markup). Я набросаю новый интерфейс для sc-памяти в ближайшие дни с использованием ios_base. Что касается внутренней кодировки, то она может понадобиться лишь для названий операций к примеру. Я за использование UTF-8. Для реализации мы будем использовать boost скорее всего, но в интерфейсы из него ничего не попадет, тем самым разработчики не будут вынуждены иго использовать. Чтобы реализовать плагины можно задействовать очень простой и удобный механизм, который я реализовывал в MyGUI. Чтобы его перенести под наши нужды понадобиться не большое количество времени, при этом он кроссплатформенный. DenisKoronchik Сообщение ZhitkoVA » 19 ноя 2011, 11:11 продолжение конструктивного обсуждения в http://www.ostis.net/forum/viewtopic.php?f=9&t=293 ZhitkoVA