So, since every service is a network of objects with a meaningful tree-like substructure, and every site's UI implies an API (in fact, an API can be generated from UI), we can treat every website as a tree of interactive interfaces. In fact, some databases and API browsers have somewhat like file-managers, but they are reinventing a file system. So, why not to extend the operating systems with filesystems instead.
The mountable sites would be created by defining new kind of drivers, that transfer the features of their semantically high level objects (such as products, news items, contacts, etc.), to the records, that then get serialized as files in a system through (e.g., FUSE), allowing you to mount them as a filesystem, where files correspond to records of those remote sites, but carry all available actions with them.
This way, if you mount a messenger, you get a disk, with all the messages, which you can filter, delete, reply, and do all other defined operations for their types (e.g., accessible via command line or right-click drop-down). If you delete them from disk, they get automatically deleted from the serivce. If you copy them, they automatically get "scraped" into your disk, etc.
Mountable sites would make it possible to use any programming language to access the features available in the sites without programming an API.-- Mindey, Jun 11 2019 MetaDrive user story https://wiki.mindey...rive-user-story.mp4[marked-for-outcome] [Mindey, Dec 08 2021] MetaDrive project and funding page https://infinity.fa...oject/854/metadriveI'm planning to organize a conference on this, and see where this could go. [Mindey, Dec 08 2021] Super User: Why is "Everything is a file" unique to the Unix operating systems? https://superuser.c...x-operating-systemsSO style discussion on the unix paradigm that is close to this. [zen_tom, Dec 08 2021] "Yes, but not generalized. There's what to do." https://xkcd.com/927/ [pertinax, Dec 15 2021] #note# The neural networks of human brain may also have meaningful tree-like substructures of their semantically high level objects, implying, that this could be a way to think of mounting specialized parts of brains to OSes.-- Mindey, Jun 15 2019 Isn't this dropbox?-- pertinax, Jun 15 2019 Not at all. Based on the description of the idea, doing something like:
mount netflix.com
Should mount all the movies on the netflix, to your OS drive, as if it is extra hard disk with all the movies, comments, and whatever the netflix has, where, if you delete a movie you've created, it is deleted from the netflix itself...
mount youtube.com
Would do the same with the other service.
mount halfbakery.com
And you have a disk on your OS with all the Ideas, which again, you can actually respond to without opening halfbakery itself.
It's certainly not what dropbox does.-- Mindey, Jun 15 2019 So, are you proposing a protocol for mounting existing websites, or a new website which supports such a protocol?
If the former, then why would, say, netflix want to give you file- system-like access to all their resources? If the latter, then it still looks a lot like dropbox to me.-- pertinax, Jun 15 2019 > So, are you proposing a protocol for mounting existing websites, or a new website which supports such a protocol?
Actually, closer to the former, realized through system of drivers, that are written for whatever resources are on the web, actually making existing resources into mountable ones. By creating the new kind of drivers for existing websites, those websites would be made into mountable websites.
> If the former, then why would, say, netflix want to give you file- system-like access to all their resources?
They wouldn't. However, it is just an example of how it would work conceptually. For example, in the case of youtube, if the resource is created by yourself, you would be able to delete it.
The websites wouldn't have to do anything other than operate as usual. The drivers written for them would take care of providing whatever features that are allowed on the websites.-- Mindey, Jun 15 2019 I was a little worried from the title that this was going to be a pitch for interactive porn with dedicated VR suites.-- Skewed, Jun 15 2019 [Skewed], well one can certainly imagine a proper driver for that.-- Mindey, Jun 15 2019 // The drivers written for them would take care of providing whatever features that are allowed on the websites. // Do you envision these drivers being written by the open source community or by the web service. I guess most likely some of each. Since many services are ad supported, it seems that this would in many cases make it easier to use the service without the ads. In that case they wouldn't write a driver and might frequently change the site just enough to break a 3rd party driver.
Not that this isn't a good idea...-- scad mientist, Dec 08 2021 [scad mientist], I think, yes, for unstable resources there may be payment required, and for stable resources, open source community would write free drivers. Often, the services with public APIs even provider their drivers implemented in multiple languages, so some lightweight syntax sugar would be enough to plug them in.-- Mindey, Dec 08 2021 I quite like this idea - and would be tempted to consider some application that can mount anything* as a file system.
* where "anything" here is something that meets some minimal acceptance criteria.
i) can be interpreted as a node-and-edges like tree structure (network structures supported with "link" type functionality from *nix systems)
ii) each node can be reduced to some unique-in-context text-string as a label
iii) nodes have some kind of "read" method that fetches information from them
That should do it for a read-only representation, it gets more tricky once you start CRUD-ing things. But just like you'd write a REST interface to your application, it makes sense to write some OS-file like interface at the same time. This would let your ancient computers work directly with the most up-to-date applications and interface with their data in a common os-file based form.
But you ought to be able to apply this to websites, databases, music collections, anything where data is stored, it should be accessible as via a pseudo-file system interface. I'd not be surprised if this exists in a number of different forms already.
It's a well recognised API , why not leverage it more widely? (Unix does have that "everything as a file" paradigm for drivers, data-streams and other connectivity, so there is a fairly well rehearsed precedent)-- zen_tom, Dec 08 2021 // [zen_tom]: I quite like this idea - and would be tempted to consider some application that can mount anything* as a file system.
Yes! Well, wasn't it the *nix systems idea to be able to have anything as a file, and I guess, any resource as a device? (as devices are represented as files, so, why not web systems?) :)
Aside from that, I'm thinking of organizing a conference of developers of related technologies, short-link: webdrive.mindey.com. I have invited people, like beepb00p.xyz who has developed a python library (HPI - human programming interface), a developer from treenity.pro (has a need for generic API for the web, because he has developed a generic UI generator) and [chronological] from Halfbakery, who has been working on both ontology development and querying and UI automated generation.
Recognizing programmatic access to the web, analyzing and sharing of data and resources as a general need shared need, there is an interest in furthering the development of related solutions, and coming up with desired features for such systems.
For example, I had defined something I call "Metaformat" (book.mindey.com), describing data properties that I'd like to have.
// [zen_tom]: This would let your ancient computers work directly with the most up-to-date applications and interface with their data in a common os-file based form.
I hadn't thought about this, but indeed, it would!
// It's a well recognised API , why not leverage it more widely?
That's what I mean. Probably, Rest-APIs could be very cheaply mapped via LibFuse to make them mountable. However, the authentication (other than OAuth2) is diverse, and not homogenous. Method, parameter and endpoint naming is also non-homogenous.
// I'd not be surprised if this exists in a number of different forms already.
Yes, but not generalized. There's what to do.-- Mindey, Dec 15 2021 I initially liked this. But as resources go who wins?
Mounting means the website takes some of the local personal drive and the gain is access to what ever the website drivers allow. The shared space would have to be a very advantageous data manipulation.-- wjt, Dec 15 2021 [wjt], regarding "Yet another standard" comic -- the idea is more about a reuse of an existing standard, than about a new standard. Sure, to be able to map other existing standards to one particular standard, we need to write the conversion mappings, and a language to write those conversions in. Perhaps BNF (Backus–Naur form) would suffice, but the alternatives to it may be convenient, and I was thinking of things like Metaformat, to agree just on one "polycontext metasymbol" to provide metadata across all kind of contexts. If adopted, such "standard polycontext metasymbol" would likely not need "yet another standard", and even if someone comes up with an alternative polycontext metasymbol, it wouldn't very be hard to come to a consensus one, before too much data on the internet gets annotated using any of them.-- Mindey, Dec 15 2021 //discussion on the unix paradigm// Yes I was wondering how far this idea is removed from unix path ideas... instead of ~/path/to/file you have https://hb.com/path/to/file and then you can manipulate that file as you see fit, or as the network protocol allows. FTP is perhaps closer to what seems to be envisaged than http but does anyone use ftp nowadays?
Also I don't think you are right [wjt] when you say //Mounting means the website takes some of the local personal drive// - the connection merely places the remote filesystem at a certain point in the local directory tree, no data needs copied until the user issues a copy or move command.-- pocmloc, Dec 15 2021 random, halfbakery