Концепция владельца данных
Sep. 10th, 2015 10:42 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vitus_wagnerВ традиционной парадигме 70-х годов у данных, которые лежат на диске владельца (не в смысле пользователя в многопользовательской системе, а в смысле какого-то куска программного кода) нет.
Приходи кто хочешь, бери файл, копируй, перемещай, меняй в нем байтики.
И у этого подхода есть масса преимуществ. Во-первых, прекраснореализуется toolbox phylosophy. Во-вторых, авторам приложений не нужно думать о поддержке таких операций как бэкап, или о способах передачи данных по сети - это можно поручить отдельным программам - сетевым FS, ftp-клиентам и т.д, и они прекрасно справятся с любыми данными.
Но чего-то в этой парадигме не хватает, и ее постоянно пытаются поломать. Из тех примеров, с которыми приходилось сталкиваться лично мне, первым была MacOS classic, с атрибутами creator и owner у файла. Концепция была, конечно. сильно кривая и мешала, когда нужно обрабатывать некие данные несколькими программами.
Но тем не менее, почему-то подобные концепции постоянно пытаются пролезть в энд-юзресккие операционные системы. Причем не только в виде необязательных настроек вроде ассоциации расширений с приложениями.
Вот в Андроиде, например, появился механизм Intents, который позволяет опять же работать в парадигме тулбокса, но уже над набором приложений-обработчиков данных, а не файлов. Ему, правда не хватает стандартизованных механизмов для бэкапа и обмена данными с другими устройствами, но это задумка такая - привязать пользователей к чужим облачным сервисам, чтобы нельзя было список покупок с компьютера на телефон скопировать, не пропусти в его через индексатор фирмы, торгующей контекстной рекламой.
Или для обмена данными по шнурку вместо избыточно низкоуровневого для этой цели USB Storage используют не протокол уровня файловой системы (SMB, например), а какой-нибудь PTP или MTP.
Если вдуматься, то вообще-то клиент-серверные базы данных и всякие веб-сервисы это примерно то же самое. Вместо того, чтобы хранить данные в файловом хранилище, к ним приделывают процесс, который реализует свою собственную политику доступа, и реализуют какой-то протокол взаимодействия с этим процессом. Иногда не один - вот у ЖЖ, например. есть один протокол для доступа из браузера, а второй - API для всяких программ-клиентов.
Я регулярно сталкиваюсь с описаниями OpenSource проектов, которые норовят использовать D-Bus в качестве аналога андридных интентов и передавать по ней данные от процесса-владельца данных к процессу-потребителю данных. Получается, естественно, плохо. Но упорство таких попыток о чём-то свидетельтсвует.
Я вот тут задумался над вопросом, а какая нужна надстройка над протоколом, подобным интентам, чтобы реализовать те полезные возможности файловой системы, которых нас лишает андроид, стремящийся максимально изолировать приложения друг от друга.
1. Нужен стандартизированный протокол бэкапа. То есть любое приложение, которое хоть что-то хоть где-то хранит (ну кроме очень специальных случаев вроде HSM, должно поддерживать операцию "скачать всё" и, по возможности - "скачать изменения со времен такого-то бэкапа", а также "восстановить вот это".
В принципе, даже HSM-ы можно бэкапить, если предусмотреть защиту бэкапа секретом, который хранится где-то отдельно от бэкапа.
2. Нужен стандартизованный object sharing протокол. Что-то вроде того же PTP или MTP - посмотреть какие объекты есть в библиотеке у данной программы, вытащить указанный объект в виде, пригодным для того, чтобы скормить аналогичному приложению на другом устройстве, положить объект.
Возможно, в обоих случаях нужно поддерживать что-то типа rsync-протокола, то есть возможность передачи по кускам с контролем целостности.
Ну и нужен качественный набор паттернов разделения менеджера данных и приложения с пользовательским интерфейсом. Хотя все равно хрен соблюдать будут. В мире где наиболее распространенным языком является php, созданный для того, чтобы смешивать логику и представление, идея разделения этих двух сущностей будет оставаться благим пожеланием.
Upd А придумает ли кто-нибудь третий случай операции кроме "забэкапить все" и "поделиться избранным", применимый к ЛЮБОЙ информации хранящейся на устройстве? (понятно что варианты "открыть в соответствующем приложении" и "стереть нафиг" не в счет).
Приходи кто хочешь, бери файл, копируй, перемещай, меняй в нем байтики.
И у этого подхода есть масса преимуществ. Во-первых, прекраснореализуется toolbox phylosophy. Во-вторых, авторам приложений не нужно думать о поддержке таких операций как бэкап, или о способах передачи данных по сети - это можно поручить отдельным программам - сетевым FS, ftp-клиентам и т.д, и они прекрасно справятся с любыми данными.
Но чего-то в этой парадигме не хватает, и ее постоянно пытаются поломать. Из тех примеров, с которыми приходилось сталкиваться лично мне, первым была MacOS classic, с атрибутами creator и owner у файла. Концепция была, конечно. сильно кривая и мешала, когда нужно обрабатывать некие данные несколькими программами.
Но тем не менее, почему-то подобные концепции постоянно пытаются пролезть в энд-юзресккие операционные системы. Причем не только в виде необязательных настроек вроде ассоциации расширений с приложениями.
Вот в Андроиде, например, появился механизм Intents, который позволяет опять же работать в парадигме тулбокса, но уже над набором приложений-обработчиков данных, а не файлов. Ему, правда не хватает стандартизованных механизмов для бэкапа и обмена данными с другими устройствами, но это задумка такая - привязать пользователей к чужим облачным сервисам, чтобы нельзя было список покупок с компьютера на телефон скопировать, не пропусти в его через индексатор фирмы, торгующей контекстной рекламой.
Или для обмена данными по шнурку вместо избыточно низкоуровневого для этой цели USB Storage используют не протокол уровня файловой системы (SMB, например), а какой-нибудь PTP или MTP.
Если вдуматься, то вообще-то клиент-серверные базы данных и всякие веб-сервисы это примерно то же самое. Вместо того, чтобы хранить данные в файловом хранилище, к ним приделывают процесс, который реализует свою собственную политику доступа, и реализуют какой-то протокол взаимодействия с этим процессом. Иногда не один - вот у ЖЖ, например. есть один протокол для доступа из браузера, а второй - API для всяких программ-клиентов.
Я регулярно сталкиваюсь с описаниями OpenSource проектов, которые норовят использовать D-Bus в качестве аналога андридных интентов и передавать по ней данные от процесса-владельца данных к процессу-потребителю данных. Получается, естественно, плохо. Но упорство таких попыток о чём-то свидетельтсвует.
Я вот тут задумался над вопросом, а какая нужна надстройка над протоколом, подобным интентам, чтобы реализовать те полезные возможности файловой системы, которых нас лишает андроид, стремящийся максимально изолировать приложения друг от друга.
1. Нужен стандартизированный протокол бэкапа. То есть любое приложение, которое хоть что-то хоть где-то хранит (ну кроме очень специальных случаев вроде HSM, должно поддерживать операцию "скачать всё" и, по возможности - "скачать изменения со времен такого-то бэкапа", а также "восстановить вот это".
В принципе, даже HSM-ы можно бэкапить, если предусмотреть защиту бэкапа секретом, который хранится где-то отдельно от бэкапа.
2. Нужен стандартизованный object sharing протокол. Что-то вроде того же PTP или MTP - посмотреть какие объекты есть в библиотеке у данной программы, вытащить указанный объект в виде, пригодным для того, чтобы скормить аналогичному приложению на другом устройстве, положить объект.
Возможно, в обоих случаях нужно поддерживать что-то типа rsync-протокола, то есть возможность передачи по кускам с контролем целостности.
Ну и нужен качественный набор паттернов разделения менеджера данных и приложения с пользовательским интерфейсом. Хотя все равно хрен соблюдать будут. В мире где наиболее распространенным языком является php, созданный для того, чтобы смешивать логику и представление, идея разделения этих двух сущностей будет оставаться благим пожеланием.
Upd А придумает ли кто-нибудь третий случай операции кроме "забэкапить все" и "поделиться избранным", применимый к ЛЮБОЙ информации хранящейся на устройстве? (понятно что варианты "открыть в соответствующем приложении" и "стереть нафиг" не в счет).
no subject
Date: 2015-09-10 01:01 pm (UTC)Что касается того, что "файл это именованная сущность", то к этому тоже есть некоторые претензии. Поскольку один и тот же файл у нас может существовать в разных контекстах, его идентифицирующим признаком будут разные поля его метаинформации.
Вот допустим есть у нас опера "Летучий Голландец" моего однофамильца в исполнении Венской Оперы хрен знает какого года.
Очевидно что в каталоге произведений Вагнера имя этому файлу "Летучий Голландец, Вена, xxx год".
В каталоге художественных произведений по мотивам известной легенды "Опера Вагнера", в каталоге постановок Венской Оперы ... Ну вы поняли.
А сети торрентв файл вообще будет идентифицироватья своей хэш-суммой, потому что кроме этого файла там бегают еще восемь записей того же представления, снятые другими камерами и пожатые другими кодеками,
no subject
Date: 2015-09-10 01:30 pm (UTC)%0 в чем проблема надстраивать абстракции уже поверх него?
в конце концов ведь все равно придется добавлять сущность "простой файл",
так почему бы просто не положить его в основу всего?
кроме того, меня еще лично очень прельщает идея "тотальной интроспекции" -- чтобы можно было открыть любую сущность и увидеть её в "истинном" бинарном виде... это плюс к восстановлению/расшифровке информации, анализу ошибок
\\dz вообще на другом уровне абстракции рассуждал. Его "файл не нужен" - это к конецпеции разделения устройств хранения на оперативную(энергозавиисимую) и долговременную память и разные способы адресации в ней.
это почему же?
ведь внутри него по-любому будут представлены объекты двух видов -- компактифицырованные/закодированные для постоянного хранения и они же рапарсенные для работы с ними, именованные файлы и директории и внутренние доступные по указателю потоки и блобы.
\\Очевидно что в каталоге произведений Вагнера имя этому файлу "Летучий Голландец, Вена, xxx год".
В каталоге художественных произведений по мотивам известной легенды "Опера Вагнера", в каталоге постановок Венской Оперы ... Ну вы поняли.
\\А сети торрентв файл вообще будет идентифицироватья своей хэш-суммой, потому что кроме этого файла там бегают еще восемь записей того же представления, снятые другими камерами и пожатые другими кодеками,
Да.
Именно об эту проблему я и имел в виду.
Можно придумать каакое-то удобное и эффективное внутреннее представление...
но что делать, если потом условия использования поменяются,
то это разрушит всю нашу красивую абстракцию.
А с другой стороны... всегда можно что угодно завернуть в красивый и вроде непротиворечивый пользовательский интерфейс и для пользователя оно будет выглядеть хорошо...
но внутри как обычнро -- жабы, червы и змеи. :)
То есть -- проблема архитектуры -- какую её не выбери, все равно со временем окажется что чего-то в ней не хватает, а она уже и не расширяется...
no subject
Date: 2015-09-10 01:49 pm (UTC)Проблема в том, что имя это не свойства файла. Имя это свойство записи в каталоге (так же как это было в unix-е со времен Кернигана и Томпсона).
У одного и того же файла может быть множество имен.
Если мы работаем не с "файлом вообще", а с "музыкатьной записью", "видео","электронной книгой", то у нас уже появляется возможность метаинформацию структурировать, например посредством rdf или Dublin Core (которые на самом деле есть вещи весьма универсальные)
и для каких-то каталогов даже прописать правила вида "Если мы сюда добавляем новый элемент, то его имя должно быть сформировано из вот таких полей метаданных".
Но вообще имя файла - это метка, которую присваивает тот, кто данный объект в данное место положил. То есть владелец устройства. И, главное, может легко поменять. Гораздо легче, чем. скажем, отредактировать тэги в mp3. Поэтому мне, например, крайне не нравится привычка всяких медиаплееров показывать тэги mp3-файлов ВМЕСТО имени файла в каталоге. ВМЕСТЕ - пожалуйста, показывайте. Но вообще-то тэги - это то что вместе с самим файлом прилетело, а имя - то то что Я дал.
no subject
Date: 2015-09-10 02:18 pm (UTC)то есть объект в котором хранятся и все его имена, и теги, и история изменений, и источник его появления, и средства работы с ним, и т.д., и т.п.... то есть, собственно этот "файл" -- это и есть та штука, с которой бы и хотелось работать прикладном уровне, единообразно...
Но тут и вылазит конфликт с реализацией -- вопрос, а на каком уровне все это будет достигаться?
no subject
Date: 2015-09-10 02:22 pm (UTC)Мне на самом деле очень нравится идея тэгов MP3-файлов, как структурированной метаинформации. Я хотел бы мочь на любые файлы вешать много структурированной метаинформации.
Имя файла, в такой модели, это всего лишь один атрибут метаинформации. Я даже не уверен, что он необходимый. Скажем, IMG_0387.JPG — атрибут совершенно бесполезный.
Но вот чего было делать категорически нельзя, так это пихать метаинформацию внутрь самого файла. Метаинформация должна легко редактироваться без инвалидации хэшей содержимого. Все тэги должны быть тем, что Я дал (или получил откуда-то вместе с содержимым).
no subject
Date: 2015-09-10 02:31 pm (UTC)А вот является ли метаинформация частью файла, или нет - это вопрос интересный и неоднозначный.
С одной стороны, очень хочется, чтобы её можно было распространять вместе с самим файлом. Для этого она должна быть частью файла и учитываться при вычислении его хэша - иначе как проверишь, что это тот же файл который ты распространял?
С другой стороны локальный override метаинформации без нарушения хэш-суммы файла - тоже дело иногда полезное бывает. Но потом будет большой облом, если ты этот файл скопируешь на другое устройство, и скопируется только метаинформация, содержащаяся в самом файле. Ну вот скачиваешь с флибусты десяток книг одного автора, а FBReader их раскидывает по трем разным написаниям имени этого автора.
Поэтому, скажем, в случае электронных книг я однозначно за метаинформацию внутри. Исправление метаинформации в этом случае ничем не отличается от исправления опечаток и ошибок OCR внутри текста. А те уж точно повлияют на хэш-сумму.
С другой стороны, я не редактирую некоторые из имеющихся у меня в коллекции mp3-шек audacity только потому, что лениво. А то бы стоило где-то отрезать треп исполнителя со зрителями перед началом пения, где-то громкость выравнять со всей остальной коллекцией, где-то аккуратно подчистить след от царапины на магнитофонной ленте, с которой это цифровалось.
no subject
Date: 2015-09-10 02:49 pm (UTC)Имя вида IMG_0387.JPG — это бесполезный атрибут. Он более прямо заменяется парой <связь с фотоаппаратом, таймштамп достаточной точности> или тройкой <связь с фотоаппаратом, таймштамп недостаточной точности, последовательный уникализатор>. (Фактически, UUID версии 1.)
Вопрос «метаинформация внутри или снаружи» решается контейнерами. Файл упаковывается в архив вместе со своей метаинформацией. С точки зрения файла метаинформация снаружи, с точки зрения архива — внутри. Но архивы должны быть легко распаковываемы и перепаковываемы.
no subject
Date: 2015-09-12 09:18 am (UTC)Так отож.
Много вы знаете архивов, которые поддерживаются ОСью.
По сути это зип... но он слишком примитивный
И каб... но он слишком закрытый и фиг знает что в нем там...
no subject
Date: 2015-09-12 11:40 am (UTC)Архивы не должны поддерживаться ОСью. Архивы должны поддерживаться архиваторами, которые должны реализовывать API, определённое неким стандартом.
Имея стандарт на API архиватора, уже можно реализовывать хоть файловый менеджер, прозрачно входящий в архивы, хоть vfs-модуль, монтирующий архивы как часть файловой системы.
Кроме того, архив должен иметь документированный открытый формат и использовать документированные свободные от патентных обременений алгоритмы сжатия.
no subject
Date: 2015-09-10 02:32 pm (UTC)no subject
Date: 2015-09-10 02:40 pm (UTC)И естественно:
The signing-time attribute MUST be a signed attribute or an
authenticated attribute; it MUST NOT be an unsigned attribute,
unauthenticated attribute, or unprotected attribute.
no subject
Date: 2015-09-10 02:57 pm (UTC)no subject
Date: 2015-09-12 09:29 am (UTC)Где на уровне приложения... можно сделать все что угодно, и удобно и понятно для пользователя.
Например как версионность в офисном документе
Но внутри оно будет запутано и наружу не представлять никаких инструментов работы,
таких чтобы можно было его объединить с другими продуктами и получить более богатую функциональность.
Можно сделать на уровне службы/сервиса/демона -- там уже внутренности более гладкие, потому что есть внешний интерфейс и более менее понятно кому и как он должен предоставляться... но со внешним взаимодействием (комбинирование с другими службами) и универсальностью все так же не очень.
А можно вообще опустить на уровень ядра... как ЗФС в Солярке,
и получить "бесплатную" версионность и универсальность... но, при этом во многом теряется юзабилити... и все так же, сложности с комбинированием функциональности.
В целом... получается проблема с дизайном -- нужно уметь учитывать и просчитывать взаимодействие и все побочные случаи.
И в этом на самом деле причина того что софтваре инжиниринг сейчас буксует -- не может выдать на гора что-то, чтобы превышало хоть по некоторым параметрам предыдущие продукты...
а не в недостатках ООП, преимуществах ФП, растущей глупости программистов, заговоре корпораций или чем-либо еще...
no subject
Date: 2015-09-13 05:30 pm (UTC)Ну вот и проблема: нет сколько-нибудь утрясшегося формата/протокола для работы с этой информацией, а с именами файлов разобраться слегка успели (юникод и длинные имена ещё не всюду, правда).
no subject
Date: 2015-09-13 05:42 pm (UTC)