Концепция владельца данных

[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 А придумает ли кто-нибудь третий случай операции кроме "забэкапить все" и "поделиться избранным", применимый к ЛЮБОЙ информации хранящейся на устройстве? (понятно что варианты "открыть в соответствующем приложении" и "стереть нафиг" не в счет).

Comments

[rvb]

В MTP для обмена данными по шнурку некий смысл есть - можно не отмонтировать раздел на мобильном устройстве и не останавливать приложения, с ним работающие.

[wizzard]

собственно, SMB тоже не требует отмонтирования :)

[rvb]

Но требует поднятия IP-over-USB.

А USB Storage - отмонтировали на устройстве, изображаем на USB флешку. Как отцепили - примонтируем обратно и пытаемся понять, что нам там успели напортачить.

[psn84.livejournal.com]

В MTP смысел однозначно есть. Не было бы оно ещё таким кривым.

[vitus_wagner]

А можно подробнее - какой именно?

Понятно что оно connectionless и отмонтировать не надо.

Но чем оно лучше даже не сетевой файловой системы вроде NFS и SMB, а протокола передачи файлов вроде ftp?

[alll]

> Нужен стандартизованный object sharing протокол.

Ну вот SMB например чем вам не угодила? "Посмотреть какие объекты есть в библиотеке у данной программы, вытащить указанный объект в виде, пригодным для того, чтобы скормить аналогичному приложению на другом устройстве, положить объект" - всё есть.

[wizzard]

обьект имеет интерфейс с методами обычно

[vitus_wagner]

В данном случае объект это блоб, помеченный media-type. Более ничего. Единственное что мы с ним можем сделать в рамках "object sharing interface" - это передать его в другую программу, умеющую обрабатывать объекты такого media type, возможно, воспользовавшись какой-то программой-посредником, обеспечивающей передачу файлов между устройствами.

Вот "список объектов" в этом протоколе должен быть более интересной сущностью.

[alll]

Неа. Объект имеет vptr на "интерфейс с методами" обычно. ;)

[wizzard]

ну и с identity там всё не так просто. но вообще да, я за. только не надо говорить что файлы могут изобразить любые обьекты :)

[vitus_wagner]

Файлы могут изобразить любые объекты. Потому что так или иначе в период выключения компьютера объект будет хранится в виде файла (файлов). А несколько файлов всегда можно заархивировать в один.

[alll]

В файловой системе есть более другие объекты, чем "файлы в узком смысле". :)

[vitus_wagner]

smb здесь не угодила в первую очередь структурой каталога. Каталог в SMB (и вообще в файловой системе) это не более чем список строк. А здесь нам нужно что-то более интеллектуальное - возможность показать (т.е. запросить у владельца данных и получить в стандартном виде) какую-то метаинформацию, thumbnail etc.

В файловой системе, конечно, есть стандартизованная метаинформация, возвращаемая системным вызовом stat. Но ее мало. thumbnail там, например, нет. Ссылок на другие каталоги (тэги), где может присутствовать тот же объект - тоже нет.

[tzirechnoy.livejournal.com]

Вероятно, тем, что единственная разумно доступная реализацыя SMB на клиенте для создателей дров камер -- это та, что в комплекте винды. Кривая, дырявая, с большыми проблемами авторизацыи и совместного использования.

[fau74.livejournal.com]

Очевидный третий случай - "проверить актуальность". Соответствует ли блок информации данному экземпляру своего бэкапа?

[vitus_wagner]

Эта функция - скорее часть протокола бэкапа (вернее, ее отсутствие - недоработка протокола бэкапа), чем третий протокол.

[inkelyad.livejournal.com]

А набор протоколов DLNA (https://en.wikipedia.org/wiki/Digital_Living_Network_Alliance) не подойдет? Он, правда, слишком сильно именно на аудио-видео-картинки заточен, но, возможно, это исправимо. Медиасервер (не путать с плеером, контроллерам и прочим зоопарком из этой спецификации) на устройстве на первый взгляд не сильно от сервера той же самбы отличается.

[vitus_wagner]

Не, не пойдет.

Во-первых, там про сети. А я про взаимодействие между приложениями локально.

Я как раз против того, чтобы позволять каким попало приложениям лазить в сеть. Работой с сетью должны заниматься специальные, выделенные приложения, написанные людьми, понимающими что такое информационая безопасность.

Во-вторых, там предусмотрено разделение устройств на хранители и потребители. За это по-моему стоит убивать с громким воплем "Копираст!".

1, Любое устройство, на котором можно смотреть контент, должно обладать возможностью долговременного хранения хотя бы одного элемента (книги, фильма etc) этого контента. Ибо никто никому постоянную connectivity не обещал.

2. Любое устройство, способное хранить эту самую единицу контента, должно способно по требованию пользователя эту единицу отдать на другое стройство. Вот сидишь ты где-нибудь в очереди в поликлинике, где никакие беспроводные протоколы не работают по причине помех от магнитно-резонансного томографа, читаешь со смартфона книжку. К тебе подходит приятель, и спрашивает "что ты такое читаешь, дай посмотреть". Если ты не можешь тут же скопировать эту книжку ему на планшет, то это жестокий DRM.

Понятно, что всякие организации злобных вендоров будут рекламировать именно такие решения.

[allter]

Третий вариант - распечатать (впрочем, это частный случай либо "поделиться", либо "бэкапа", в зависимости от способа, которым владеет печатающая программа).
Разные варианты фильтров-обработчиков, впрочем, тоже можно считать частным случаем "поделиться".

Ещё можно рассмотреть такую операцию, как "задержать до определённого момента/снапшот". Которую также можно реализовать как создание ссылки (которая будет существовать, даже если другой клиент удалит контент).

Про зоопарк клиент-серверных протоколов и прибамбасов для обработки данных: Проблема тут не в том, что протокола нет, а в том, что информации стало очень много, её трудно искать и зарождается экономика основанная на обработке информации (и в частности на запрещении/затруднении к ней доступа техническими методами).

В конце концов, HTTP+WebDAV предоставляют приличное количество стандартных глаголов для управления контентом. И навесить их поверх USB достаточно просто. Но вот сидит какой-то архитектор или аналитик, читает записку "разработать механизм, что бы можно было фоточки скидывать не отмонтируя SD-карту", и думает: 1) зачем ему плодить лишнюю точку возможных подводных камней на стыке USB и HTTP_over_USB?; 2) чем заменить в новом протоколе host:port (т.е. потребуется сделать какую-то подсистему поиска/перечисления приложений/фоток на обоих сторонах)? 3) Как все эти сложности с обеспечением интероперабельности помогут (точнее, не помешают) заработать? И в результате рождается велосипед, который, хоть и коряво, но едет туда, куда нужно.

И так получается, даже если в исходной задаче для архитектора нет требования обеспечить явный lock-in. Просто недостаток времени и прочих ресурсов на изучение best practices приводит к тому, что если бы вдруг электроннной почты по каким-то причинам не было бы до сих пор, то сейчас она возникла бы в виде каких-нибудь "Google messages", которыми бы пользовались лишь пользователи гугла.

Нам лишь остаётся пытаться остаться на предыдущем уровне технологического уклада и как минимум сохранять на своих компьютерах традиционные файловые системы, rsync, программы, которые работают с файлами как с файлами, а не как своими личными БД и т.д.

[vitus_wagner]

"Распечатать" это очень неуниверсальная задача. Ну как можно распечатать видеофайл? Или музыкальную запись? Игру в тетрис?

Ну то есть стандартизовать это надо по принципу "Если приложение реализует функцию печати объекта, API должен быть такой-то".

Разные варианты фильтров-обработчиков - это скорее всего. либо "альтернативное приложение, умеющее работать с объектами такого типа" (ну, возможно, неинтерактивное, да, либо хрень требующая абсолютно другого API, применимого не "ко всем объектам, которые могут храниться". Например, могу себе представить протокол для индексатора полнотекстового поиска. С вариантами для звуковых файлов "позвать имеющуюся в системе распознавалку голоса", "взять хэш и сходить в imdb за lyrics".

То есть если мы делим приложение на "хранилку", "обработчик" и UI, то и печать, и полнотекстовый поиск - это интерфейсы не храники, а обработчика. Они должны слишком много знать о внутреннем устройстве информационного объекта. Настолько много, что дешевле потерпеть UI, если его не удается отделить от обработчика (а, скажем, рендеринг для печати может составлять как бы не 90% UI).

[alkach42.livejournal.com]

Еще операция - получить список удаленного и "прополоть" по нему существующее.

[inkelyad.livejournal.com]

По поводу возможных операций.

"Получить доступ к файлу" чтобы скопировать, забакапить, переслать, вложить внутрь какого-нибудь документа и "Получить доступ к информации в файле" чтобы просмотреть, процитировать, отредактировать различать будем?

Оно слегка не одно и то же.

[vitus_wagner]

Ну так мы это с самого начала различаем. Предполагая что у нас есть приложение, которое умеет получать доступ к информации в файлах данного типа. И оно внутри себя эти файлы хранит, никому не рассказывая как именно, и никому не давая доступа непосредственно в хранилище (как это в норме делается в Андроиде). И вот мы хотим придумать API, который позволяет по минимуму огранмчивая свободу действий приложения в организации своего хранилища, получить свободу пользователя по поводу получать и распространять информацию, и защищать её от мелких неприятностей в виде утраты хранящего её устройства.

Соответственно, API для получения доступа к информации, которое приложение предоставляет (если предоставляет) другим приложениям на устройстве, существенным образом зависит от типа этой информации. А мы тут обсуждаем API, которое будет общим для любой информации, про которую мы знаем только то, что она хранится на устройстве, а не где-то в облаке.

[livelight]

> Если вдуматься, то вообще-то клиент-серверные базы данных и всякие веб-сервисы это примерно то же самое. Вместо того, чтобы хранить данные в файловом хранилище, к ним приделывают процесс, который реализует свою собственную политику доступа, и реализуют какой-то протокол взаимодействия с этим процессом. Иногда не один - вот у ЖЖ, например. есть один протокол для доступа из браузера, а второй - API для всяких программ-клиентов.

Суть-то таки не в политике доступа, она вторична, а в том, что у каждой базы данных есть некая схема и набор ограничений. Если любой желающий сможет сходить в глубины жж по файловому протоколу (или, как вариант, по SQL, причём с правом не только на DML, но и на DDL) и написать в эти файлы произвольный набор байт (а файл - это произвольный набор байт), то даже при очень добронамеренных желающих структура жж с пользователями, постами и комментами быстро превратится в тыкву.

[vitus_wagner]

Ну так по-моему политика доступа и есть набор ограничений.

Заметим, что многие файловые форматы отнюдь не проще по устройству, чем база данных (а зачастую они этой базой данных и являются). Взять те же офисные форматы документов. Это совершенно не мешает с ними работать как с файлами.