Концепция владельца данных
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 А придумает ли кто-нибудь третий случай операции кроме "забэкапить все" и "поделиться избранным", применимый к ЛЮБОЙ информации хранящейся на устройстве? (понятно что варианты "открыть в соответствующем приложении" и "стереть нафиг" не в счет).
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2015-09-10 08:29 am (UTC)no subject
Date: 2015-09-10 08:31 am (UTC)no subject
Date: 2015-09-10 08:40 am (UTC)Ну вот SMB например чем вам не угодила? "Посмотреть какие объекты есть в библиотеке у данной программы, вытащить указанный объект в виде, пригодным для того, чтобы скормить аналогичному приложению на другом устройстве, положить объект" - всё есть.
no subject
Date: 2015-09-10 08:44 am (UTC)А USB Storage - отмонтировали на устройстве, изображаем на USB флешку. Как отцепили - примонтируем обратно и пытаемся понять, что нам там успели напортачить.
no subject
Date: 2015-09-10 08:48 am (UTC)no subject
Date: 2015-09-10 08:48 am (UTC)no subject
Date: 2015-09-10 08:55 am (UTC)no subject
Date: 2015-09-10 09:04 am (UTC)Вот "список объектов" в этом протоколе должен быть более интересной сущностью.
no subject
Date: 2015-09-10 09:07 am (UTC)В файловой системе, конечно, есть стандартизованная метаинформация, возвращаемая системным вызовом stat. Но ее мало. thumbnail там, например, нет. Ссылок на другие каталоги (тэги), где может присутствовать тот же объект - тоже нет.
no subject
Date: 2015-09-10 09:08 am (UTC)no subject
Date: 2015-09-10 09:10 am (UTC)no subject
Date: 2015-09-10 09:11 am (UTC)Понятно что оно connectionless и отмонтировать не надо.
Но чем оно лучше даже не сетевой файловой системы вроде NFS и SMB, а протокола передачи файлов вроде ftp?
no subject
Date: 2015-09-10 09:14 am (UTC)no subject
Date: 2015-09-10 09:14 am (UTC)no subject
Date: 2015-09-10 09:21 am (UTC)2. Речь идет о том, что SMB работает поверх любого низкоуровнего протокола коммутации пакетов. Поэтому можно, чтобы не возиться с IP, сделать новый такой протокол, заточенный на работу поверх USB. Ну примерно также как в свое время сделали сам USB, а не стали использовать ethernet и POE там, где сейчас USB. У этого решения и правда могут быть преимущества.
3. Поднять IP over USB должно быть действительно проще. Со стороны андроида - это вообще задача близкая к тривиальной. В режиме модема он именно так и работает. Со стороны винды вроде тоже этому уже научились, судя по распространенности модемов с интерфейсом USBNet. Осталось только научиться запускать на андроиде SMB-сервер. и в режиме USB-модема давать хосту нормальный доступ к самому устройству по IP. К моему удивлению широко распространенного и бесплатного SMB-сервера для андроида нет.
no subject
Date: 2015-09-10 09:24 am (UTC)no subject
Date: 2015-09-10 09:25 am (UTC)Потому что этот протокол предназначен как раз для копирования отдельных содержательных кусков информации между устройствами и между программами-менеджерами информационных архивов на одном устройстве.
Кстати с точки зрения файловой системы в традиционном юниксе он тоже далеко не полноценный файл. Например, нельзя раздать содержащую его файловую систему по NFS и получить на десткопе доступ к его данным.
no subject
Date: 2015-09-10 09:25 am (UTC)no subject
Date: 2015-09-10 09:28 am (UTC)Что касается FTP/NFS/SMB - их надо ещё научить бегать поверх USB без прослойки с эмуляцией ethernet. А МТП - вот оно, криво-косо и не всегда, но работает.
Но вообще, конечно, МТП - лютое говно и надо его яростно закапывать. Хотя бы в пользу FTP-over-USB.
no subject
Date: 2015-09-10 09:31 am (UTC)yep. я предлагаю их как-то по-другому называть, хотя хороший термин что-то сходу не придумывается :(
no subject
Date: 2015-09-10 09:34 am (UTC)Симлинки - это не более чем способ организовать каталог объектов так, чтобы один и тот же объект можно было находить разными способами.
Я полагаю, что вместо термина "симлинки" правильнее использовать более общий термин "ссылки" (ссылки на данный объект могут быть из разных каталогов в рамках зоны ответственности данного менеджера данных) А как физически организованы эти ссылки - как симлинки, хардлинки, записи в БД или гипертекстовые файлы с гиперссылками - внутреннее дело менеджера данных.
Или на содержательном уровне использовать термин "тэги".
Этот термин хорош тем, что неявно предлагает способ передачи этой метаинформации вместе с объектом и корректного её использования в системе каталогов на целевом устройстве.
no subject
Date: 2015-09-10 09:42 am (UTC)Я согласен с тем, что термин "объект" избыточно широк. Он избыточно широк для почти любого контекста, кроме конкретного объектно-субъектного взаимодействия.
Термин "документ" избыточно узок. Обычно мы не воспринммаем фильм или картинку как документ (хотя ничего противоестественного в таком словоупотреблении нет). "Документ" это что-то из области офисной жизни, в области entertainment ему места нет.
Термин medium - ещё хуже. Он вообще применяется к подобным сущностям скорее в смысле наоборот. Medium - это носитель, а не сообщение. Здесь же речь идет скорее о сообщении, чем о носителе. Термин "сообщение" тоже плох. Распространение Instant Messenger-ов привело к тому. что с понятием "сообщение" ассоциируется не более абзаца текста. И уж никак не полнометражный фильм.
В Communiware мы в свое время использовали термин item. Но item подчеркивает несамодостаточность этого объекта, того что он часть чего-то большего. А здесь смысл в том, что это самодостаточный кусок информации, его можно передать из одной библиотеки в другую, и он там не потеряет смысла.
Можно попробовать покрутиться вокруг термина content. Благо понятия content consumption и content creation сейчас употребляются почти в том смысле, в каком надо.
Но content - это такое обобщенное слово, как "sheep" в английском или "рыба" или "зерно" в русском. Оно означает как один элемент, так и целое стадо/косяк/мешок.
no subject
Date: 2015-09-10 09:44 am (UTC)no subject
Date: 2015-09-10 09:47 am (UTC)Странно, что никто не попытался реализовать smb-сервер тем же способом, каким реализовали ssh-сервер или openvpn-клиент: - берем широко известную опенсурсную реализацию, компилим ее NDK и приделываем GUI-обвязку.
no subject
Date: 2015-09-10 10:15 am (UTC)оверехед ethernet на мелких пакетах просто гигантский.