|
Единое пространство данных - базовое описание |
Ниже изложено базовое описание единого пространства данных 3ОС. Впервые оно было дано в документе "Моя 3ОС". Настоящий вариант практически полностью повторяет авторский оригинал.
Далее речь пойдет о том, что в традиционных системах носит название виртуальной файловой системы (ВФС). В 3ОС система доступа к хранимым данным базируется на иных принципах, и фактически будет представлять собой совокупность вложенных объектов. Поэтому и решено было назвать ее по-другому. Традиционное понятие файла также не предусматривается.
Ранее предлагалось использовать концепцию "контейнер-кодек-поток" (ККП). Она получила одобрение участников проекта, и теперь считается базовой в 3ОС, наряду с УО Андрея Милова. Приведенное ниже описание строится именно на концепции ККП и является его авторским изложением.
В этом разделе будет показано, что переименование всем хорошо знакомой ВФС в пространство данных является не просто косметическим изменением или погоней за модой, а чем-то более весомым.
Основной недостаток существующих сред хранения - отсутствие строгой типизации данных. Фактически все данные могут быть интерпретированы как простой поток байтов, что часто идет вразрез как с идеологией ООП, так и самой природой данных. Ведь не бывает данных вообще, все они имеют определенный формат, который желательно было бы закрепить на уровне операционной системы.
Другой недостаток традиционных ВФС заключается в их узкой ориентированности практически только на дисковые устройства хранения. Даже сетевые устройства представляются с помощью дисковых парадигм. Все остальное, что не может быть втиснуто в узкие рамки дискового мышления, считается "специализированным" и требует дополнительных программ, т. е. уже не является частью традиционной ВФС.
Поэтому, понятие единого пространства данных 3ОС исходит из следующих постулатов:
Хорошим примером типизированной гетерогенной среды является Web. Все ресурсы, хранящиеся в сети WWW, имеют строго определенный MIME-тип, а стандарты протокола HTTP позволяют получить данные, не заботясь о их конкретном источнике (например, статическая страница HTML, или данные БД, обрабатываемые некой CGI-программой). Перенося идеи, положенные в основу Web, на уровень ОС, получаем единое пространство данных.
Прежде чем начать описание, приведем список понятий, раскрываемых далее. Итак, концепция "контейнер-кодек-поток" строится на следующих базовых понятиях:
Рассмотрим их по порядку.
Понятие потока - основа любой ВФС. Под потоком понимается абстракный набор данных, связанный с некоторым физическим или логическим устройством. Для нас является важным то, что формат данных в потоке никак не оговаривается, и их интерпретация (или отсутствие таковой) возлагается на использующие поток программы.
С точки зрения ОО можно также сказать, что существует интерфейс потока. Его, пожалуй, знают все - как класс поток описан в любой ОО-библиотеке. Интерфейс потока включает в себя три основных метода:
Не все перечисленные операции применимы ко всем потокам. Могут существовать потоки:
Способность позиционировать указатель на данные является отдельным свойством. По нему потоки подразделяются на:
Понятие абстрактного потока в ККП ничем не отличается от традиционного. Например, адепты UNIX могут считать его обычным потоком UNIX, обернутым в оболочку ОО (хотя это не совсем верно - в 3ОС нет понятия "ОО-оберток").
Далее по тексту термин "поток" может обозначать как абстрактный поток (интерфейс потока), так и другое понятие, используемое в ККП - поток хранения. Например, в самом названии "контейнер-кодек-поток" под потоком подразумевается именно поток хранения.
Поток хранения - это поток, связанный с конечным устройством ввода-вывода. Можно сказать, что поток хранения является прикладным интерфейсом драйвера какого-то устройства или логического модуля ОС.
В концепции ККП поток хранения олицетворяет собой конечную точку ВФС, далее которой идут устройства. Можно также сказать, что на потоке хранения кончается прикладной (высокий) уровень абстракции, и начинается слой драйверов, низкоуровневых служб и т. п.
На диаграмме поток хранения обозначается узлом, имеющим один вход (выход, вход-выход). Поскольку поток хранения реализует интерфейс абстрактного потока, к нему применимы все его свойства: только для чтения, прямой доступ и т. д.
Примеры потоков хранения:
Кодеком называется объект, преобразующий данные. По логике, кодек имеет:
Соответственно, кодек реализует два интерфейса потока: один для входа, а другой - для выхода. К обоим потокам применимы свойства абстрактного потока, но с оговорками:
Следует также отметить, что с точки зрения ООП, кодек абстрактным потоком не является, он просто реализует два его интерфейса, соответственно имея два свойства типа "абстрактный поток".
В концепции ККП кодеки занимают промежуточное звено, находясь между потоками хранения и контейнерами. На диаграмме кодек обозначается как узел, имеющий две точки соединения - вход и выход.
Примеры кодеков:
Как дальнейшее развитие абстракции кодеков, наверняка стоит подумать над вариантами с несколькими входами или выходами. В данной концепции подобные кодеки не рассматриваются.
Объект данных - это устойчивый объект, содержащий некоторые прикладные (по отношению к пространству данных) данные. Интерфейс устойчивого объекта не отличается от традиционного:
В качестве параметра оба метода получают интерфейс потока ввода-вывода.
Особо отметим факт, что прикладные программы 3ОС не работают напрямую с потоками. Парадигма объекта данных позволяет иметь дело не с набором байтов, а с четко типизированными данными.
С прикладной точки зрения, объект данных является минимальным "кирпичиком", конечной точкой и для пространства данных, и для прикладной программы. Дальнейшее деление объекта данных невозможно: то, что находится внутри него, полностью интерпетируется и обрабатывается кодом объекта данных.
С концептуальной точки зрения, объект данных представляется как начальное звено пространства данных, на котором кончается прикладная программа, и начинается собственно, само пространство. На диаграмме объект данных обозначается как узел, имеющий косвенные (логические) связи с потоками данных.
Также, ни один объект данных не ограничивается одной лишь реализацией интерфейса устойчивого объекта. Он всегда реализует собственные, прикладные методы для доступа к данным, находящимся внутри него. Например, объект данных "текст" может возвращать число строк, добавлять и удалять строки и т. д.
Примеры объектов данных очевидны:
Еще один взгляд на объекты данных рассматривается в следующей главе, посвященной контейнерам.
Следует особо отметить, что, работая с объектами в пространстве данных, прикладные программы не создают экземпляров кодеков или потоков - это за них делает объект данных. В этом и состоит самое главное отличие пространства данных от среды традиционных ОС, где потоки создаются прикладными программами.
Контейнер данных (абстрактный контейнер, далее просто "контейнер") - составной объект данных, т. е. объект данных, состоящий из нескольких вложенных в него объектов данных. Рассуждая от противного, можно также сказать, что объект данных является вырожденным случаем контейнера, содержащего только один объект.
С точки зрения ООП, контейнер является самостоятельным классом, не связанным наследованием с объектом данных. Интерфейс абстрактного контейнера содержит единственный метод, возвращающий объект данных. Подразумевается, что объект данных находится внутри контейнера, и каким-то образом выбирается из нескольких, если таковые присутствуют. Способ выбора конкретного объекта отличается для разных контейнеров.
Забегая немного вперед, отметим, что некоторые типы контейнеров (в частности, перечислимый первичный контейнер) все-таки являются специальным случаем объекта данных, и соответственно, реализует интерфейс устойчивого объекта. Такие контейнеры могут вкладываться друг в друга, перемешиваясь с объектами данных.
В концепции ККП контейнер является базовым абстрактным понятием, на котором строятся дальнейшие рассуждения о пространстве данных.
Данный вид контейнера является самым простым в ККП. В соответствии с логикой, считается, что неперечислимый контейнер содержит некоторое число объектов данных, но:
Как следствие, доступ к объектам внутри неперечислимого контейнера производится установкой его дополнительных свойств: путь, имя объекта, смещение, длина, система отсчета и т. д.
Унаследованный от абстрактного контейнера, неперечислимый контейнер не имеет нового абстрактного интерфейса. Он реализует метод, возвращающий объект данных, и добавляет методы для чтения/записи его дополнительных свойств. В принципе, введение в ККП понятия неперечислимого контейнера служит исключительно целям типизации.
Примеры неперечислимых контейнеров чаще связаны в сетью:
Как следует из названия, перечислимый контейнер содержит в себе конечное число объектов данных, которые могут быть последовательно получены из него простым перечислением. Для доступа к объектам внутри себя перечислимый контейнер создает специальный вспомогательный объект, называемый перечислителем.
Перечислитель нужен для того, чтобы обойти ограничения, связанные с неизвестностью конкретного числа объектов в контейнере. Большинство последовательных контейнеров могут вернуть число содержащихся в них объектов, только пересчитав их по одному. Последнее может оказаться далеко не быстрой операцией. Вот тут-то и помогает перечислитель. Очень часто программам не обязательно знать точное число объектов, достаточно знать, является ли данный объект последним в контейнере.
Аналогичные перечислители используются в Java, и называются итераторами. Перечислитель реализует два основных метода:
Согласно концепции, контейнер может создать несколько перечислителей одновременно, удовлетворяя несколько поступивших запросов. Соответственно, экземпляры перечислителей независимы друг от друга.
В ККП перечислимый контейнер является предком для последовательного контейнера и контейнера прямого доступа.
Последовательный контейнер представляет собой класс, реализующий интерфейс перечислимого контейнера. На уровне концепции было целесообразно разделить понятия абстрактного перечислимого контейнера и последовательного контейнера, чтобы не было путаницы с наследованием.
Как говорилось выше, последовательный контейнер "не знает" точного количества помещенных в него объектов, но может их пересчитать по одному при помощи перечислителя. Поскольку фактическое перечисление объектов в контейнере может быть связано с чтением с диска, или посылкой сообщений по сети, введение отдельного класса для последовательного по природе контейнера полностью оправдано.
Примеры последовательных контейнеров:
Перечислимые контейнеры бывают двух типов - последовательные и прямого доступа. Последовательные контейнеры не имеют дополнительных свойств, по сравнению с абстрактными перечислимыми контейнерами. Контейнеры прямого доступа, наоборот, имеют несколько дополнительных методов:
Как видно, прямой доступ к объектам контейнера может осуществляться по индексу. Контейнер прямого доступа является аналогом списков или коллекций в традиционных ОО-библиотеках.
По примеру Java, прямой доступ может эмулироваться на любом последовательном контейнере. Например, доступ по индексу реализуется как переход в начало (получение нового перечислителя) и пропуск нужного числа объектов. Для удобства программирования наверняка так и придется сделать, однако нужно отметить, что программы обязательно должны точно знать, имеют ли они дело с настоящим прямым доступом или его эмуляцией. Именно для этого в предыдущей главе и был введен тип последовательного контейнера.
Примеры контейнеров прямого доступа:
Любой перечислимый контейнер может также являться иерархическим. По определению, иерархический контейнер может возвращать перечислители, дающие доступ не ко всем, а только к некоторым объектам данных, отобранных по тому или иному признаку.
Интерфейс иерархического контейнера наследуется от перечислимого, добавляя новый метод - возврат перечислителя с параметром. Получается, что иерархический контейнер может выступать как в роли обычного перечислимого, так и в роли иерархического, грубо говоря, нескольких перечислимых "подконтейнеров".
В зависимости от природы, иерархические контейнеры могут иметь как последовательный, так и прямой доступ. В случае вложения контейнеров друг в друга, интерфейс иерархического контейнера позволит обойти все объекты данных, находящиеся на уровнях, начиная с заданного.
Примеры иерархических контейнеров:
По отношению к помещенным в него объектам данных, любой контейнер пространства данных является:
Дальнейшие пояснения, думаю, не нужны. С точки зрения традиционных ВФС, понятие первичных и вторичных контейнеров, вкупе с иерархичностью, думается, полностью покрывает понятия вложенных каталогов, а также жестких и символических ссылок на файлы.
Для именования объектов данных концепция ККП предлагает использовать URL. На то есть три причины:
URL 3ОС состоит из двух частей:
Используются следующие служебные символы:
Все остальные символы интерпретируются, как есть. Здесь и выше под словом "символы" подразумеваются символы UCS32. В случаях, когда использование UCS32 невозможно, символы не из набора ASCII представляются их кодами, в соответствии с существующими правилами формирования URL.
Например, адрес сайта 3ОС http://www.3os.ru/ может быть преобразован к виду: http:www.3os.ru. Аналогично, почтовая ссылка mailto:coordinator@3os.ru может быть записана как mailto://coordinator@3os.ru/. В 3ОС обе записи равнозначны и поддерживаются на уровне пространства данных.
Данная концепция не устанавливает ограничений на длину URL. Однако, в целях совместимости с существующими стандартами, некоторые пространства имен могут накладывать свои ограничения на длину URL.
С точки зрения ККП важным является также то, что в URL перечисляются только контейнеры и объекты данных, кодеки и потоки лежат на более низком уровне. Поскольку мы ранее причислили объекты данных к контейнерам, можно сказать, что в URL указываются только контейнеры.
В традиционных ВФС существует понятие корневого каталога или просто корня. К нему монтируются узлы дисковой ФС и отображаемые устройства.
В 3ОС пространство данных имеет более глобальный характер, и его корень, соответственно, будет иметь несколько иной смысл. Пространство данных 3ОС едино, и может содержать как перечислимые, так и неперечислимые контейнеры. Значит, полное перечисление всех объектов в пространстве данных невозможно, и, в принципе, не нужно. Поэтому, прикладным программам не потребуется обращаться к корню пространства данных целиком. Это - самое главное отличие корня пространства данных от корня традиционных ВФС.
Корень пространства данных 3ОС представляет собой перечислимый контейнер, содержащий пространства имен. Опираясь на правила URL, принимается, что корень пространства данных обозначается знаком ":" (двоеточие).
С альтернативной точки зрения, корень пространства данных также может рассматриваться как диспетчер пространств имен.
Пространством имен называется контейнер, монтируемый к корню пространства данных и обслуживаемый специальной программой - диспетчером пространства имен. Как правило, пространство имен образуют объекты, использующие общий транспорт для доступа к ним.
В соответствии с приведенными выше правилами, пространства имен обозначаются идентификаторами, после которого идет двоеточие. Примеры пространств имен:
Поскольку пространства имен являются контейнерами, к ним применимы все свойства контейнеров. В приведенном выше примере: file:// и user:// - перечислимые иерархические контейнеры, а остальные - неперечислимые иерархические.
Понятие пространства имен является достаточно гибким, и покрывает все возможности существующих ВФС. Поскольку обработка пространства имен возлагается целиком на его диспетчер, возможно подключение к единому пространству данных т. н. отображаемых пространств имен, представляющих аналоги отображаемых устройств в традиционных системах. Главное отличие - в строгой типизации: отображаемые пространства имен должны содержать не потоки неформатированных данных, а строго типизированные объекты.
В 3ОС наверняка будут существовать специализированные пространства имен, определяемые системой. Например, будет целесообразным монтирование пространства имен, представляющего аналог реестра Windows. Самое главное - выбрать правильный стиль именования и разобраться со стандартами префиксов URL, которые и являются в 3ОС идентификаторами пространств имен.
Для целостности картины введем также понятие неименованного пространства имен. Для каждой программы неименованное пространство является пространством имен по умолчанию. Пока неясно, какие объекты оно должно содержать. Объекты в неименованном пространстве имен имеют URL без начального префикса. Работа неименованного пространства имен обеспечивается специальным диспетчером, создаваемым системой при запуске программы. Можно сказать, что диспетчер неименованного пространства имен является частью среды выполнения программы. Неименованное пространство имен обязательно является отображаемым, т. е. вторичным контейнером объектов. Отображая неименованное пространство имен на разные фактические пространства, получаем ОО-аналог переадресации устройств ввода-вывода в UNIX. Но в UNIX мы ограничены консолью и дисковыми устройствами (отображаемыми как диски), а в едином пространстве данных такого ограничения не будет.
Разбор URL, целесообразно будет возложить на контейнеры, ссылки на которые представлены в URL. Таким образом будет достигнута максимальная независимость механизма разбора от конкретно используемых классов контейнеров. Разбор будет производиться следующим образом:
Как видно из описания, эта схема не имеет ограничений ни на класс используемых контейнеров, ни на количество их вложения. Следует также учитывать, что иерархические контейнеры могут интерпретировать сразу несколько частей (токенов) URL за один раз, поэтому четкой связи "один токен - один контейнер" не существует.
Оппоненты могут возразить, что для элементарного разбора URL в память придется грузить сразу несколько классов, что может сильно замедлить работу системы. Тут приходится согласиться, что за универсальность и независимость метода разбора придется платить повышенными накладными расходами. К тому же, загрузка в память кода контейнеров потребуется для последующего доступа к запрашиваемому объекту, поэтому для части случаев она может быть вполне оправдана. Для остальных случаев придется применить оптимизацию, методы которой описываются далее.
Чтобы минимизировать повторную загрузку данных с носителей, обычно используют кэширование. В существующих ОС кэширование происходит на уровне системы и представляет собой, по сути, хранение прочитанных данных в специально отведенной области памяти, называемой кэшем. Для нас является важным тот факт, что данные хранятся в неформатированном виде, т. е. практически также, как они представлены на кэшируемом носителе.
Поскольку хранение данных в виде набора байтов идет вразрез со строгой типизацией, для кэширования пространства данных 3ОС предлагается воспользоваться т. н. объектным кэшем, который описывается ниже. Объектный кэш может применяться как для кэширования программ, так и данных, поскольку и те, и другие в 3ОС представляют собой объекты.
Для минимизации чтения данных из вложенных контейнеров можно использовать отложенное чтение при обращении к контейнерам. Оно будет рассмотрено нами после объектного кэша.
Суть объектного кэша в том, что данные в памяти представляются не в виде низкоуровневого набора байтов, а в виде экземпляров программ или объектов данных. Грубо говоря, вся процедура кэширования сводится к тому, что экземпляры объектов после использования не уничтожаются, а продолжают находиться в памяти до тех пор, пока не потребуется ее перераспределение. Не могу вспомнить точно, но где-то такая технология точно применялась, у меня даже стоит перед глазами пункт в настройках "Weak package loading".
Понятно, что такой подход к кэшированию позволяет снизить накладные расходы на использование оперативной памяти. В случае традиционного кэширования, данные хранятся в памяти дважды:
У объектного кэша оба пункта совмещены, т. к. данные хранятся сразу в виде готового объекта, для использования которого никаких дополнительных действий не требуется.
Можно сказать, что кэширование на уровне объектов дает практически двукратную экономию памяти по сравнению с традиционным кэшем.
Насколько известно, нечто похожее существует в Windows. По заверениям Microsoft, страницы дискового кэша могут стать страницей кода или данных программы без копирования ее содержимого. Естественно, это применимо только для случаев, когда не требуется преобразования хранящегося в кэше образа.
Размышляя над алгоритмом объектного кэширования, можно прийти к выводу, что работа объектного кэша - это не что иное, как сборка мусора. Ведь их принципы в чем-то похожи: объект не уничтожается, а остается на попечении системы контроля за использованием ресурсов. Разница в следующем:
Следовательно, должен существовать механизм идентификации объектов в кэше, чтобы диспетчер кэша мог точно определить, содержится ли запрашиваемый объект в кэше, или его потребуется создавать заново.
Возможно, в некоторых случаях определенный выигрыш производительности может дать наличие некоторого пула наиболее часто используемых объектов, как это делается в COM (модель apartment, если мне не изменяет память). Может быть, пулы объектов использует какой-либо сборщик мусора, пусть это подтвердят или опровергнут наши эксперты. Если пулы действительно используются, встает вопрос об объединении сборщика мусора с механизмом объектного кэширования в одно целое. Получится интересное следствие: сборщик мусора, встроенный в систему, является не тормозом, потребляющим память и мешающим работе программ, а средством кэширования объектов. Если подходить к сборке мусора именно с этой точки зрения, получается, что она должна быть не просто приятной функцией, облегчающей написание программ прикладникам, а одной из ключевых особенностей ОС и пространства данных, в частности.
Согласно постулатам, изложенным выше, объект данных может находиться в многократно вложенных контейнерах. Давайте внимательно рассмотрим, какие действия потребуются для доступа к такому объекту. Под доступом мы подразумеваем следующее:
Какие при этом будут произведены действия?
Все начнется с синтаксического разбора URL, для чего в память последовательно будут загружены все контейнеры, стоящие на пути к объекту. Ранее мы говорили, что именно контейнеры и объекты данных являются источниками или приемниками на всем пути от носителя к программе. Экземпляры кодеков и потоков создаются именно ними. Для сокращения времени доступа к объектам данных и снижения накладных расходов, предлагается задействовать метод оптимизации, названный ранее отложенным чтением из вложенных контейнеров.
Что представляет собой экземпляр объекта данных? Не следует думать о нем, как о полной копии набора данных в памяти. Данных может быть много, и памяти просто не хватит. По сути, объект данных - это не более чем оболочка над низкоуровневым потоком данных объекта. Самих данных он не содержит, а только предоставляет к ним доступ, точно также как и поток. Поэтому, когда создается объект данных, в памяти фактически создаются некоторые контрольные структуры, определяющие его формат, свойства, и т. д. Если для получения формата и инициализации начальных свойств объекта данных не требуется создание потока, он не создается. Данные же непосредственно начинают читаться только тогда, когда запрашиваются прикладной программой. Если поток не был создан до этого времени, он создается.
Поскольку на объект данных возлагается функция кэша, он может и должен кэшировать данные объекта в памяти, вместо того, чтобы читать их непосредственно из потока. В принципе, буферизация может быть легко автоматизирована на уровне абстракного объекта данных, поэтому при реализации конкреных объектов данных дополнительно ничего не придется программировать, или писать надо будет мало.
С учетом того, один и тот же объект данных может быть запрошен разными программами, для них должен иметься единый объектный кэш на уровне пространства данных, который будет отслеживать запросы программ, и по необходимости создавать транзакции для объектов, изменяемых несколькими программами одновременно. Это решение во многом перекликается с концепцией удаленных объектов. Кажется, правильно работающий объектный кэш станет вершиной реализации УО в 3ОС.
В принципе, нет никаких препятствий для реализации отложенной записи данных через вложенные контейнеры. Все сказанное выше, применимо и для записи данных. Запись, в некотором смысле, даже проще, т. к. формат и свойства задаются прикладной программой, поэтому предварительное создание потоков вообще не требуется. Естественно, следует учитывать проблемы, с которыми обычно сталкиваются при реализации отложенной записи в обычном кэше.
Как говорилось выше, строгая типизация является основой пространства данных. Также было принято, что для именования объектов в пространстве используется URL. URL содержит имена контейнеров на пути к объекту данных, а также имя самого объекта данных. Однако, URL не предоставляет никаких сведений о типе объекта. Вспомним Web - при обращении по некоторому URL браузер вначале запрашивает MIME-тип документа (объекта данных), интерпретирует его, и только потом начинает его загрузку и обработку.
Описанный подход имеет один большой недостаток. Он применим для чтения данных, но мало пригоден для их записи и поиска. Контейнеры могут поддерживать различные форматы посредством кодеков и потоков. Давайте подумаем, как можно его обойти.
Выделим следующие важные следствия именования объектов при помощи URL:
Ранее предлагалось решить проблему типизации при помощи т. н. "описателей контента". Предложение оказалось не очень удачным, т. к. создавало много проблем с синхронизацией фактического типа объекта и его описателя, а также невозможность создания универсального языка описания любых, заранее неизвестных типов данных при помощи базового набора примитивов.
Данная концепция предлагает следующее:
Следствия:
Примеры:
Повторимся - для традиционных файловых систем введение дополнительного описателя типа данных является чуждым, и противоречит идеологии файлов как простого набора байтов. Следовательно, для них мы должны задействовать автоматическое распознавание типа данных по их фактическому формату, основанное на т. н. детекторе сигнатур.
Для правильного определения типа данных в тех средах хранения, где это не предусмотрено самой средой, пространство данных должно обеспечить его автоматическое распознавание. Для реализации этого механизма каждый класс объекта данных должен реализовывать специальный метод, возвращающий булевское значение, представляет ли переданный поток "его данные".
Естественно, метод распознавания типа должен быть объявлен на уровне абстрактного интерфейса объекта данных, чтобы его можно было реализовать в потомках.
Поскольку все объекты данных в 3ОС являются специализированными классами, ситуации, когда один класс объекта данных обрабатывает два разных типа данных, невозможна. Это является ключевым для пространства данных. Даже если в целях оптимизации фактический код может классов может использоваться повторно, для целей строгой типизации соответствие один тип данных (некий идентификатор) - один обработчик (объект данных, контейнер) должно соблюдаться в обязательном порядке.
Как было сказано выше, для описания процесса создания и поиска объектов можно разработать специальный язык. Возможно, именно этот язык и будет называться DML.
Следует обратить внимание, что язык будет чисто описательным, т. е. не будет содержать каких-либо команд. Представляется, что такого рода описательный язык лучше всего создать на основе XML.
Далее мы рассмотрим, что должен описывать наш язык для каждой операции, объявленной специализированной:
Для создания объекта в пространстве данных требуется следующая информация:
В процессе создания объекта нас ждут следующие трудности:
Если URL указывает на несуществующий контейнер, получается, что в процессе создания конечного объекта фактически должно быть создано несколько объектов. В принципе, такое можно и запретить, но, наверное, будет все-таки лучше, если описательный язык позволит создавать несколько вложенных объектов за один раз, возвращая при этом ссылку на объект на самом внутреннем уровне вложенности. Поскольку будет создано несколько объектов, для каждого из них должен быть задан тип контейнера и набор вложенных кодеков. Например, таким образом можно будет создать несколько вложенных папок ФС, или архив в архиве.
Не все контейнеры являются универсальными, т. е. могут принимать объекты ограниченного набора типов. Если создаваемый объект не может быть помещен в контейнер, на который указывает URL, контейнер должен вызвать исключение, которое будет передано вызывающей стороне. Сам объект при этом создан не будет.
Для поиска объекта в пространстве данных требуется следующая информация:
Из приведенного списка только URL является обязательным параметром, а все остальные могут быть опущены.
В процессе поиска объекта возможна только одна ошибка, связанная с идеологией единого пространства данных - URL может указывать на неперечислимый контейнер. Как следует из определения, поиск объекта может производиться только в перечислимых контейнерах. Поскольку пространство данных может содержать в себе и неперечислимые контейнеры, поиск по всему пространству данных невозможен.
В принципе, в неперечислимых контейнерах поиск объекта может быть произведен при помощи специализированных поисковых машин, как сейчас это делается в Интернете. Вполне возможно, что в будущем подобный сервис может быть очень даже развит, если учитывать темпы общего развития Интернета.
Мы можем предусмотреть возможность поиска при помощи поисковых машин и включить ее в язык. Чтобы процесс поиска протекал единообразно для всех неперечислимых контейнеров и поисковых машин, потребуется создание специальных объектов-посредников, которые из шаблона на нашем языке будут формировать запрос к поисковику, а потом интерпретировать полученный ответ и выдавать его программам в стандартной форме. Согласно концепции единого пространства данных, поиск должен быть прозрачен для всех случаев.