Есть данные в моём приложении (допустим, картинки). И есть много чужих приложений, которые работают с файлами-картинками (скринсейвер-фотоальбом, менеджер обоев и т.п.). И, получается, чтобы подать им данные на вход, нужно изобразить папку с файлами.
Для этого есть какие-то стандартные инструменты? Куда копать? Желательно, мультиплатформенно, но винда нужна в первую очередь.
Здравствуйте, Alekzander, Вы писали:
A>Для этого есть какие-то стандартные инструменты? Куда копать? Желательно, мультиплатформенно, но винда нужна в первую очередь.
Nextcloud реализует такое. Если поставить "использовать виртуальную ФС" в настройках, то в проводнике будут отображаться файлы из облака, но физически они будут загружаться только в момент первого чтения. Исходники открыты. А вообще — https://learn.microsoft.com/en-us/windows/win32/projfs/projected-file-system первая ссылка в выдаче, вы даже не пытались
Здравствуйте, Alekzander, Вы писали:
A>Есть данные в моём приложении (допустим, картинки). И есть много чужих приложений, которые работают с файлами-картинками (скринсейвер-фотоальбом, менеджер обоев и т.п.). И, получается, чтобы подать им данные на вход, нужно изобразить папку с файлами.
A>Для этого есть какие-то стандартные инструменты? Куда копать? Желательно, мультиплатформенно, но винда нужна в первую очередь.
Представится файлом — хз, а папками — это расширения оболочки могут, все вот эти "Мои Документы" так и сделаны
Здравствуйте, Marty, Вы писали:
M>Представится файлом — хз, а папками — это расширения оболочки могут, все вот эти "Мои Документы" так и сделаны
Но только они папки только для оболочки и для программ, которые для доступа к файловой системе используют ее API. А для тех, кто использует системный API, их нет.
Здравствуйте, cppguard, Вы писали:
C>вы даже не пытались
Виновен, ваша честь. Хотел сначала послушать про возможные подходы. ФС, или, может, какой-то механизм, на который опирается реализация subst и обратная ей команда (название забыл), или драйвер, или что-то ещё.
M>>Представится файлом — хз, а папками — это расширения оболочки могут, все вот эти "Мои Документы" так и сделаны
Pzz>Но только они папки только для оболочки и для программ, которые для доступа к файловой системе используют ее API. А для тех, кто использует системный API, их нет.
Имхо ты не прав, но 100%-но утверждать не буду. Но вроде бы АПИ само там подстановки делает, как надо. Ну это АПИ юзерского уровня, если ядрёное — то там да, никаких подстановок точно не будет
Здравствуйте, Marty, Вы писали:
A>>Есть данные в моём приложении (допустим, картинки). И есть много чужих приложений, которые работают с файлами-картинками (скринсейвер-фотоальбом, менеджер обоев и т.п.). И, получается, чтобы подать им данные на вход, нужно изобразить папку с файлами.
A>>Для этого есть какие-то стандартные инструменты? Куда копать? Желательно, мультиплатформенно, но винда нужна в первую очередь.
M>Представится файлом — хз, а папками — это расширения оболочки могут, все вот эти "Мои Документы" так и сделаны
У таких папок, сколько мне помнится, гуид, а надо путь. Что прописать, например, в строке "Путь к изображениям" в виндовом реестре, откуда explorer берёт новую картинку для обоев по таймауту?
Здравствуйте, Marty, Вы писали:
Pzz>>Но только они папки только для оболочки и для программ, которые для доступа к файловой системе используют ее API. А для тех, кто использует системный API, их нет.
M>Имхо ты не прав, но 100%-но утверждать не буду. Но вроде бы АПИ само там подстановки делает, как надо. Ну это АПИ юзерского уровня, если ядрёное — то там да, никаких подстановок точно не будет
Здравствуйте, Alekzander, Вы писали:
A>>>Есть данные в моём приложении (допустим, картинки). И есть много чужих приложений, которые работают с файлами-картинками (скринсейвер-фотоальбом, менеджер обоев и т.п.). И, получается, чтобы подать им данные на вход, нужно изобразить папку с файлами.
A>>>Для этого есть какие-то стандартные инструменты? Куда копать? Желательно, мультиплатформенно, но винда нужна в первую очередь.
M>>Представится файлом — хз, а папками — это расширения оболочки могут, все вот эти "Мои Документы" так и сделаны
A>У таких папок, сколько мне помнится, гуид, а надо путь. Что прописать, например, в строке "Путь к изображениям" в виндовом реестре, откуда explorer берёт новую картинку для обоев по таймауту?
Это все не важно. Важно то, что стороннее приложение может открыть диалог открытия файлов, там среди прочего будет "Мои Документы\Моё супер-пупер приложение", там пользователь может выбрать файл, а приложению будет отдан реальный путь к файл в файловой системе.
Да, я соврал в ответе Pzz, CreateFile этим не занимается, этим шелл апи занимается, через которое, в тч, отображается диалог открытия файла
Но, допустим, я в проводнике перехожу в "Документы", там в FFOutput. Кликаю на адресной строке, там — "копировать", в буфер попадает "C:\Users\USER\Documents\FFOutput"
Здравствуйте, Alekzander, Вы писали:
A>Кто-нибудь делал такое?
В линухе это легко и непринужденно делается с помощью fuse.
Вроде как есть порт под венду (https://github.com/winfsp/winfsp), х.з., насколько работоспособный.
A>Есть данные в моём приложении (допустим, картинки). И есть много чужих приложений, которые работают с файлами-картинками (скринсейвер-фотоальбом, менеджер обоев и т.п.). И, получается, чтобы подать им данные на вход, нужно изобразить папку с файлами.
А не проще ли эти файлы просто вывалить во временную директорию? Диски нонече быстрые и дешевые, так что если картинок там не терабайт, это может оказаться вполне годным вариантом...
Здравствуйте, Alekzander, Вы писали:
C>>вы даже не пытались
A>Виновен, ваша честь. Хотел сначала послушать про возможные подходы. ФС, или, может, какой-то механизм, на который опирается реализация subst и обратная ей команда (название забыл), или драйвер, или что-то ещё.
Ну, точки монтирования и хард/софт линки тоже никто не отменял, но тебе таки свои файлы где-то надо хранить где-то на NTFS, но можно подставлять почти куда хочешь — хард линки только в рамках тома, софт линки — где угодго.
Вот чего я так и не понял, так это почему в винде по умолчанию хард линки разрешены, а софт линки запрещены
Здравствуйте, Pzz, Вы писали:
Pzz>CreateFile ничего не знает про шеловские папки.
Да, я наврал, этим занимаются функции, которые показывают диалоги открытия/сохранения ффайла и прочего — они в приложуху отдают имя файла в файловой системе, а если получают, то пытаются отобразить его на виртуальную папку, и если удалось, то показывают в диалоге виртуальную папку
M>Вот чего я так и не понял, так это почему в винде по умолчанию хард линки разрешены, а софт линки запрещены
Запрещены нелокальные симлинки (и то не все).
C:\>fsutil behavior query symlinkevaluation
Local to local symbolic links are enabled
Local to remote symbolic links are enabled.
Remote to local symbolic links are disabled.
Remote to Remote symbolic links are disabled.
Здравствуйте, m2user, Вы писали:
M>>Вот чего я так и не понял, так это почему в винде по умолчанию хард линки разрешены, а софт линки запрещены
M>Запрещены нелокальные симлинки (и то не все).
M>
M>C:\>fsutil behavior query symlinkevaluation
M>Local to local symbolic links are enabled
M>Local to remote symbolic links are enabled.
M>Remote to local symbolic links are disabled.
M>Remote to Remote symbolic links are disabled.
M>
Что такое — нелокальные симлинки?
mklink не создаёт никакие софт линки без специального разрешения для этого. Может, через АПИ это по другому, я глубоко не копал
симлинки, у которых хотя бы одна из сторон (сам симлинк, либо место куда он указывает) на сетевом каталоге.
Но эта настройка про поведение при переходе по симлинку, а не про создание.
M>mklink не создаёт никакие софт линки без специального разрешения для этого. Может, через АПИ это по другому, я глубоко не копал
Да, ты прав. Политика "Create Symbolic Links" по умолчанию дает права на создание только группе Администраторов.
Но можно создавать junction point (mklink /j), для них достаточно прав на запись в каталог.
Здравствуйте, m2user, Вы писали:
M>>mklink не создаёт никакие софт линки без специального разрешения для этого. Может, через АПИ это по другому, я глубоко не копал
M>Да, ты прав. Политика "Create Symbolic Links" по умолчанию дает права на создание только группе Администраторов. M>Но можно создавать junction point (mklink /j), для них достаточно прав на запись в каталог.
junction point — это врде как про каталоги. А я хотел, чтобы условно сделать симлинк на C:\qt5.12\toolchain\gcc\bin\gcc.exe по пути C:\MyBins\gcc7.exe, и при запуске C:\MyBins\gcc7.exe у него было окружение из C:\qt5.12\toolchain\gcc\bin
Не хочу добавлять всё в пути, но хочу иметь доступ ко всему нужному, добавив в PATH единственный путь C:\MyBins, и присовывая туда то, что нужно.
Не могу понять, какого хрена в винде эта возможность по умолчанию заблокирована
Здравствуйте, Alekzander, Вы писали:
A>Кто-нибудь делал такое?
A>Есть данные в моём приложении (допустим, картинки). И есть много чужих приложений, которые работают с файлами-картинками (скринсейвер-фотоальбом, менеджер обоев и т.п.). И, получается, чтобы подать им данные на вход, нужно изобразить папку с файлами.
A>Для этого есть какие-то стандартные инструменты? Куда копать? Желательно, мул ьтиплатформенно, но винда нужна в первую очередь.
Здравствуйте, Alekzander, Вы писали:
A>Кто-нибудь делал такое?
A>Есть данные в моём приложении (допустим, картинки). И есть много чужих приложений, которые работают с файлами-картинками (скринсейвер-фотоальбом, менеджер обоев и т.п.). И, получается, чтобы подать им данные на вход, нужно изобразить папку с файлами.
A>Для этого есть какие-то стандартные инструменты? Куда копать? Желательно, мультиплатформенно, но винда нужна в первую очередь.
Это будет очень тяжело. В винде есть т.н. "reparse points", на них основаны и симлинки. Для работы с этим вам придётся писать драйвер файловой системы, да не простой, а для Installable File System.
Если я правильно помню, монтирование файлов .wim в некую папку опирается на этот механизм, вы получаете иерархию из кучи файлов и папок, папки настоящие, а файлы указывают на внутренности определённого файла wim.
Ещё недавно я наткнулся на неведомый механизм app alias, это когда у вас есть как бы исполняемые файлы в C:\Users\Username\AppData\Local\Microsoft\WindowsApps\, а на самом деле это особого вида ссылки, например wsl.exe ссылается на C:\Program Files\WindowsApps\MicrosoftCorporationII.WindowsSubsystemForLinux_2.4.10.0_x64__8wekyb3d8bbwe\wsl.exe, но вероятно это сделано только для определённых задач и вам не пригодится.
Здравствуйте, Marty, Вы писали:
A>>У таких папок, сколько мне помнится, гуид, а надо путь. Что прописать, например, в строке "Путь к изображениям" в виндовом реестре, откуда explorer берёт новую картинку для обоев по таймауту?
M>Это все не важно.
Как это "не важно", когда это часть юз-кейса? Диалога открытия файла (как и Explorer'а в любом виде) может вообще не быть, а путь к виртуальному файлу прописывается где-нибудь в конфиге.
Здравствуйте, Pzz, Вы писали:
Pzz>А не проще ли эти файлы просто вывалить во временную директорию? Диски нонече быстрые и дешевые, так что если картинок там не терабайт, это может оказаться вполне годным вариантом...
И потом их синхронизировать в обе стороны? (Изменения в файлах отражать в данных приложения, изменения в данных приложения отражать в файлах). Мне кажется, это плохой путь.
Здравствуйте, m2user, Вы писали:
A>>Для этого есть какие-то стандартные инструменты? Куда копать? Желательно, мультиплатформенно, но винда нужна в первую очередь.
M>Как вариант — запускать локальный ftp-сервер. Windows Explorer хорошо умеет с ftp работать.
А приложения? )) Есть, например, MPC-HC. Который делает очень специфический автор. Я его просил закрепить вывод оставшегося времени на экран (сам вывод уже был), а он мне ответил: купи себе часы. Могу представить, что он посоветует, если его попросить поддержать работу с видеороликами по FTP. Между тем, программа популярная, у дохрениллиона юзеров установлена.
M>Потестил ещё: при открытии файла через winexplorer на редактирование он копируется с ftp во временные файлы пользователя.
Я ещё не знаю, надо ли давать редактирование файла, но на всякий случай хотелось бы.
Здравствуйте, Qulac, Вы писали:
A>>Кто-нибудь делал такое?
A>>Есть данные в моём приложении (допустим, картинки). И есть много чужих приложений, которые работают с файлами-картинками (скринсейвер-фотоальбом, менеджер обоев и т.п.). И, получается, чтобы подать им данные на вход, нужно изобразить папку с файлами.
A>>Для этого есть какие-то стандартные инструменты? Куда копать? Желательно, мул ьтиплатформенно, но винда нужна в первую очередь.
Q>В paint image можно скопипастить если что.
Это совет по выгрузке данных в файлы, как выше ("А не проще ли эти файлы просто вывалить во временную директорию?"), но только без автоматизации, или я не понял какую-то изюминку?
Здравствуйте, Pzz, Вы писали:
Pzz>В линухе это легко и непринужденно делается с помощью fuse.
Pzz>Вроде как есть порт под венду (https://github.com/winfsp/winfsp), х.з., насколько работоспособный.
Мне кажется, FUSE это единственное вменяемое решение по вопросу топикстартера. Там ещё упомянули https://en.wikipedia.org/wiki/Installable_File_System, но это хардкор тот ещё — хоть и является официальным и правильным для ОС Windows.
A>А приложения? )) Есть, например, MPC-HC. Который делает очень специфический автор. Я его просил закрепить вывод оставшегося времени на экран (сам вывод уже был), а он мне ответил: купи себе часы. Могу представить, что он посоветует, если его попросить поддержать работу с видеороликами по FTP. Между тем, программа популярная, у дохрениллиона юзеров установлена.
Если приложение (вернее пользователь приложения) работает с файлом на FTP через диалог winexplorer, то приложению про ftp ничего знать не нужно. Файл автоматом скопируется во временные для чтения и редактирования.
При сохранении (если пользователь выбрал сохранять на ftp) — загрузится обратно (внутри этот механизи работает через internet explorer).
Если у тебя работа с файлами может происходить вообще без win exporer (т.е. должна быть возможность вручную прописать путь), то это сложнее.
Можно посмотреть в сторону webdav (http), который можно монтировать как сетевой диск, в отличие от ftp.
Вопрос в том, сколько времени/денег ты собираешься в это вложить. Можно ведь и коммерческую лицензию на winfsp, который предлагали ранее, купить за $2400/6000, можно погрузится в собственную реализацию installable file system.
А может быть проще обучить твое приложение подхватывать файлы из указанной директории.
P.S. subst просто добавляет DosDeviceName как ссылку на указанный путь.
Здравствуйте, m2user, Вы писали:
A>>А приложения? )) Есть, например, MPC-HC. Который делает очень специфический автор. Я его просил закрепить вывод оставшегося времени на экран (сам вывод уже был), а он мне ответил: купи себе часы. Могу представить, что он посоветует, если его попросить поддержать работу с видеороликами по FTP. Между тем, программа популярная, у дохрениллиона юзеров установлена.
M>Если приложение (вернее пользователь приложения) работает с файлом на FTP через диалог winexplorer, то приложению про ftp ничего знать не нужно. Файл автоматом скопируется во временные для чтения и редактирования. M>При сохранении (если пользователь выбрал сохранять на ftp) — загрузится обратно (внутри этот механизи работает через internet explorer).
M>Если у тебя работа с файлами может происходить вообще без win exporer (т.е. должна быть возможность вручную прописать путь), то это сложнее. M>Можно посмотреть в сторону webdav (http), который можно монтировать как сетевой диск, в отличие от ftp.
Как-то это всё выглядит ненадёжно. Кроме того, я помню, как работал с webdav'ом (давно, правда) — постоянно какие-то грабли, и вдобавок тормозило.
Здравствуйте, flаt, Вы писали:
F>Мне кажется, FUSE это единственное вменяемое решение по вопросу топикстартера. Там ещё упомянули https://en.wikipedia.org/wiki/Installable_File_System, но это хардкор тот ещё — хоть и является официальным и правильным для ОС Windows.
Ну в линухе народ тоже, когда надо богатый внутренний мир программы представить в виде файловой системы, предпочитает использовать fuse, а не пилить полноценные файловые системы (хотя в линухе это в разы проще, чем в венде, и если чего непонятно, есть, где подглядеть).
Разница в том, что в линухе fuse — фактически, часть ОС. Чего не скажешь про венду.
Здравствуйте, Alekzander, Вы писали:
A>получается, чтобы подать им данные на вход, нужно изобразить папку с файлами.
Нет, не нужно. Более того — это последнее, что должно приходить в голову.
Вообще, простейший проверочный вопрос для оценки полезности любой идеи: "если так начнут делать все, как это будет восприниматься с моей стороны?".
A>Для этого есть какие-то стандартные инструменты?
Разумеется — функции типа "send", "share" и т.п. В винде это DDE, Drag-and-drop и подобное.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Вообще, простейший проверочный вопрос для оценки полезности любой идеи: "если так начнут делать все, как это будет восприниматься с моей стороны?".
Если бы каждая программа давала файловый view на свои данные, а не пыталась как последняя падла скрыть их, делая себя с понтом незаменимой, я бы сказал, что попал в инженерный рай.
>Разумеется — функции типа "send", "share" и т.п. В винде это DDE, Drag-and-drop и подобное.
Ты задачу не понял. А я не объяснил. (Потому что для моего вопроса это неважно). Считай, что есть база, в ней БЛОБы, и эти БЛОБы надо уметь представить как файлы. Какой send, какой share, какой DDE.
Здравствуйте, Alekzander, Вы писали:
A>Если бы каждая программа давала файловый view на свои данные, а не пыталась как последняя падла скрыть их, делая себя с понтом незаменимой, я бы сказал, что попал в инженерный рай.
А если попытаетесь чуть лучше представить, то сразу поймете, что полезли бы на стенку, или вовсе вздернулись.
A>есть база, в ней БЛОБы, и эти БЛОБы надо уметь представить как файлы.
Обмен данными между программами существует десятки лет, последние лет тридцать — весьма разнообразный. То, что в целях такого обмена до сих пор не применяется эмуляция файлов, должно бы наводить на некие мысли.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Обмен данными между программами существует десятки лет, последние лет тридцать — весьма разнообразный. То, что в целях такого обмена до сих пор не применяется эмуляция файлов, должно бы наводить на некие мысли.
Очень жаль, если ты не знаешь таких программ, но при этом даёшь очень глобальные советы так не делать, потому что так, якобы, не делает никто.
Выше написали про WebDAV. Его как раз в таких целях и использовали. В одной мелкой и мягкой компании. Этой имплементацией на основе WebDAV я пользовался сам много лет, и это было лучше, чем совсем ничего (то есть, ничего, кроме тупой выгрузки/загрузки, которую ты имеешь в виду под send/share), но хуже, чем если бы было сделано по уму. А как такие вещи делаются по уму — об этом и был мой вопрос.
Здравствуйте, Alekzander, Вы писали:
A>Очень жаль, если ты не знаешь таких программ
Если их знаете Вы — перечислите навскидку хотя бы штук пять.
A>при этом даёшь очень глобальные советы так не делать
Такие советы Вам даст любой мало-мальски компетентный в системном программировании человек, который исходит из того, чтоб не создавать уродливых костылей без крайней нужды.
A>потому что так, якобы, не делает никто.
Из вменяемых — точно никто. Если кто и сделал, то явно было похоже на Nero Burning ROM.
A>Выше написали про WebDAV. Его как раз в таких целях и использовали.
Но не внутри конкретной системы, а между ними. Это ключевое различие.
A>как такие вещи делаются по уму — об этом и был мой вопрос.
По уму такие вещи делаются в виде общесистемных служб, когда любое, заранее неизвестное приложение, пользуясь готовым API, может выставить какие-то ресурсы в заранее известных форматах. Но именно это и реализовано давным-давно в популярных системах, и любое приложение, заинтересованное в использовании чужих данных, использует соответствущие API. Вы пока не привели доводов против них, поэтому идея непременно эмулировать файлы выглядит, как прихоть, а не рациональный метод.
А если каждое приложение, которому есть, что передать другим, начнет эмулировать файлы, в системе начнутся трэш и содомия. Вот именно поэтом и не делают.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Если их знаете Вы — перечислите навскидку хотя бы штук пять.
Это типовой паттерн в классе софта, называемом СКД (системы корпоративного документооборота). Рассказывать тут, с какими из них я работаю, как и другие детали личной жизни, я воздержусь. Приведу только один пример, зато уж сразу с картинками:
Там тебе и про старый способ через WebDAV, и про новый способ через OneDrive.
Расскажи им, что они все дураки. Особенно, юзерам. Которые — видишь? Задают вопросы, как им получить проекцию БЛОБов на файловую систему. Тоже, дебилы, наверно. Раз хотят такие вещи.
P.S. Чтобы ты понимал:
Since we migrated our documentation to M365 in 2022 we do not have access (or don't know how to do it) to sites and document libraries from Microsoft Explorer on Windows 10 and 11
Здравствуйте, Alekzander, Вы писали:
A>Если бы каждая программа давала файловый view на свои данные, а не пыталась как последняя падла скрыть их, делая себя с понтом незаменимой, я бы сказал, что попал в инженерный рай.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Такие советы Вам даст любой мало-мальски компетентный в системном программировании человек, который исходит из того, чтоб не создавать уродливых костылей без крайней нужды.
Денис Ричи, Кен Томпсон, Роб Пайк — достаточно компетентнте в системном программировании граждане, или недостаточно?
Идея "всё есть файловая система" является основополагающей в Plan9...
Здравствуйте, Pzz, Вы писали:
A>>Если бы каждая программа давала файловый view на свои данные, а не пыталась как последняя падла скрыть их, делая себя с понтом незаменимой, я бы сказал, что попал в инженерный рай. Pzz>Этот инженерный рай называется Plan 9 from Bell Labs
Я бы предпочёл более другой рай, но на фоне нынешней культуры этот, конечно, достаточно райский.
Здравствуйте, Alekzander, Вы писали:
Pzz>>Этот инженерный рай называется Plan 9 from Bell Labs
A>Я бы предпочёл более другой рай, но на фоне нынешней культуры этот, конечно, достаточно райский.
Plan 9, конечно, никто не использует в чистом виде (кроме Роба Пайка), но его "растаскали по цитатам" по другим ОС.
Fuse — явное и очевидное влияние. Как и union mount, bind mount, /proc file system, linux namespaces, ...
Здравствуйте, Евгений Музыченко, Вы писали:
Pzz>>Идея "всё есть файловая система" является основополагающей в Plan9...
ЕМ>И где там API для произвольного процесса, чтоб он мог выставить что угодно под видом файлов?
Я не знаю технических деталей, но там довольно идеоматическое дело, когда процесс реализует свой интерфейс в виде файловой системы.
Причем, что характерно, програмный интерфейс GUI — это файловая система. Соответственно, подмонтировав её куда надо, получаешь доступ к экрану. Даже и удалённо по сети.
Ну а права доступа выражаются в терминах права смонтировать доступаемое в свой namespace.
Здравствуйте, Pzz, Вы писали:
A>>Я бы предпочёл более другой рай, но на фоне нынешней культуры этот, конечно, достаточно райский.
Pzz>Plan 9, конечно, никто не использует в чистом виде (кроме Роба Пайка), но его "растаскали по цитатам" по другим ОС.
Я не об этом. Мой рай это структурированные хранилища с метаданными. Очень обидно смотреть на СУБД, которые технически (но не функционально) его воплощают. Близок локоть, а не укусишь. Ну хрен ли толку, что в Андроиде половина всего (? — точно не знаю) хранится в sqlite, если менеджер контактов через три звезды колено синхронизируется через гуглосервер, и нельзя его смапить через GUI как источник данных для тасклистов.
Здравствуйте, Alekzander, Вы писали:
Pzz>>Plan 9, конечно, никто не использует в чистом виде (кроме Роба Пайка), но его "растаскали по цитатам" по другим ОС.
A>Я не об этом. Мой рай это структурированные хранилища с метаданными. Очень обидно смотреть на СУБД, которые технически (но не функционально) его воплощают. Близок локоть, а не укусишь. Ну хрен ли толку, что в Андроиде половина всего (? — точно не знаю) хранится в sqlite, если менеджер контактов через три звезды колено синхронизируется через гуглосервер, и нельзя его смапить через GUI как источник данных для тасклистов.
Была же пара операционок, у которых всё было базой данных. Но как-то не прижилось...
Здравствуйте, Pzz, Вы писали:
Pzz>там довольно идеоматическое дело, когда процесс реализует свой интерфейс в виде файловой системы.
Это ж всего лишь тяжкое наследие 60-70-х, когда концепция файловой системы была одной из самых прорывных изобретений. Мантра "всё есть файл", упорно повторяемая десятилетиями, в итоге выродилась до полной бессмыслицы вроде "бытие есть существование". Впоследствии никто больше по этому пути не пошел, ибо довольно глупо и нерационально впихивать все возможные виды интерфейсов в простенькую, но универсальную схему. Объектная модель зарекомендовала себя куда лучше.
Pzz>програмный интерфейс GUI — это файловая система. Соответственно, подмонтировав её куда надо, получаешь доступ к экрану. Даже и удалённо по сети.
И что толку? С тем же успехом (и с теми же затратами) делается объектная модель, где на том конце по умолчанию — неизвестная сущность, у которой можно спросить, кто она такая, что умеет делать, как с нею взаимодействовать, и т.п. В основе — очень просто, а расширять можно до бесконечности, практически без потери эффективности.
Здравствуйте, Alekzander, Вы писали:
A>в Андроиде половина всего (? — точно не знаю) хранится в sqlite
Скорее, 95%, а то и больше.
A>если менеджер контактов через три звезды колено синхронизируется через гуглосервер, и нельзя его смапить через GUI как источник данных для тасклистов.
Ну наколхозили Вы способ прямиком смапить его базу на какие-нибудь левые виртуальные файлы, а при очередном обновлении они поменяли формат базы, и Ваш костыль поломался — хорошо, если только сам, не потянув за собой что-то еще (поскольку работает на системном уровне, а не в рамках отдельного процесса).
Если приложение считает нужным выставлять свои данные другим, ему следует организовать Content Provider.
Здравствуйте, Евгений Музыченко, Вы писали:
A>>если менеджер контактов через три звезды колено синхронизируется через гуглосервер, и нельзя его смапить через GUI как источник данных для тасклистов.
ЕМ>Ну наколхозили Вы способ прямиком смапить его базу на какие-нибудь левые виртуальные файлы, а при очередном обновлении они поменяли формат базы
А кто говорил о "наколхозеньи"? Делать надо хорошо, а не колхозить. Это включает в себя стандартизацию форматов. Что, если разработчики ОС в каждой версии начнут менять API? А кто-то уже "наколхозил" вызовы этих API! А? Всё ведь сломается, правда же?
Но сначала я хочу услышать про Чапаева и пустоту СКД и никого, кто так не делает. Достаточно ли было приведённого выше примера, чтобы осознать, что заявления о "ником" были, мягко говоря, не совсем соответствующими действительности?
Здравствуйте, Евгений Музыченко, Вы писали:
Pzz>>там довольно идеоматическое дело, когда процесс реализует свой интерфейс в виде файловой системы.
ЕМ>Это ж всего лишь тяжкое наследие 60-70-х, когда концепция файловой системы была одной из самых прорывных изобретений. Мантра "всё есть файл", упорно повторяемая десятилетиями, в итоге выродилась до полной бессмыслицы вроде "бытие есть существование". Впоследствии никто больше по этому пути не пошел, ибо довольно глупо и нерационально впихивать все возможные виды интерфейсов в простенькую, но универсальную схему. Объектная модель зарекомендовала себя куда лучше.
Это "растащили по цитатам" по всем современным ОС. Все эти /proc file system, fuse, linux namespaces — это всё оно.
Объектная модель требует специальных инструментов даже для того, чтобы вообще посмотреть, что происходит. Если нечто имеет интерфейс файловой системы, зачастую достаточно cat и ls.
Pzz>>програмный интерфейс GUI — это файловая система. Соответственно, подмонтировав её куда надо, получаешь доступ к экрану. Даже и удалённо по сети.
ЕМ>И что толку? С тем же успехом (и с теми же затратами) делается объектная модель, где на том конце по умолчанию — неизвестная сущность, у которой можно спросить, кто она такая, что умеет делать, как с нею взаимодействовать, и т.п. В основе — очень просто, а расширять можно до бесконечности, практически без потери эффективности.
У этого "очень просто" входной порог — 1000 строк нового кода, чтобы хотя бы просто попробовать.
Здравствуйте, Pzz, Вы писали:
Pzz>Была же пара операционок, у которых всё было базой данных. Но как-то не прижилось...
Это несовместимо со стрижкой баранов. Если бы можно было управлять своими данными напрямую, а не через гуглосервер, то как бы Гугл на рекламе столько поднимал. Ему же надо социальные графы строить. Чтобы одновременно мыть мозг мужу и жене. Или там мужу и любовнице. Смотря что за товар.
Здравствуйте, Alekzander, Вы писали:
A>Делать надо хорошо, а не колхозить. Это включает в себя стандартизацию форматов.
Что "естественно и разумеется" предполагает, что общая концепция файла, как хранилища, не имеющего заранее известной структуры, для этого не годится.
A>Что, если разработчики ОС в каждой версии начнут менять API?
Если это общие, стандартизированные API — будет плохо. Если же они меняют сугубо внутренние API — это их личное дело, а те, кому приспичило на них заложиться — ССЗБ.
A>Достаточно ли было приведённого выше примера, чтобы осознать, что заявления о "ником" были, мягко говоря, не совсем соответствующими действительности?
Если Вы о примере с WebDAV, то нет, ибо он из другой оперы.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Угу, достаточно сравнить, как работают версии FAR до того, как перешли на хранение настроек в SQLite, и после этого.
Расскажи подробнее, что там не так. Я в кишках фара не копался, у меня 3.0 и я хз, использует ли оно SQLite.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Pzz, Вы писали:
Pzz>Это "растащили по цитатам" по всем современным ОС.
"Все современные" — это те, что переделаны из *nix?
Pzz>Объектная модель требует специальных инструментов даже для того, чтобы вообще посмотреть, что происходит.
Если эти инструменты уже есть в составе ОС, то какая разница, насколько они "специальны"?
Pzz>Если нечто имеет интерфейс файловой системы, зачастую достаточно cat и ls.
Этого было достаточно полста лет назад, когда нужно было впихнуть код рабочей ОС в минимально разумный объем. То, что это дотащили до наших дней, вместе с концепцией скриптовых языков, умеющих работать только с текстом — не заслуга, а карма.
Pzz>У этого "очень просто" входной порог — 1000 строк нового кода, чтобы хотя бы просто попробовать.
Здравствуйте, Философ, Вы писали:
Ф>Расскажи подробнее, что там не так.
Да хотя бы запускаться стал в десятки раз медленнее, особенно в первый раз после копирования в новую систему. Помню, сколько вою было, когда там было решено переходить на SQLite, но команда твердо стояла на своем — "это круто, профессионально, перспективно и т.п.".
Ф>Я в кишках фара не копался, у меня 3.0 и я хз, использует ли оно SQLite.
Здравствуйте, Евгений Музыченко, Вы писали:
A>>Достаточно ли было приведённого выше примера, чтобы осознать, что заявления о "ником" были, мягко говоря, не совсем соответствующими действительности?
ЕМ>Если Вы о примере с WebDAV, то нет, ибо он из другой оперы.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Обмен данными между программами существует десятки лет, последние лет тридцать — весьма разнообразный. То, что в целях такого обмена до сих пор не применяется эмуляция файлов, должно бы наводить на некие мысли.
Применяется 50+ лет как
ьтиплатформенно, но винда нужна в первую очередь.
Особенно, юзерам. Которые — видишь? Задают вопросы, как им получить проекцию БЛОБов на файловую систему. Тоже, дебилы, наверно. Раз хотят такие вещи.
