h a l f b a k e r yThere goes my teleportation concept.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
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.
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/metadrive
I'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-systems
SO 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]
Please log in.
If you're not logged in,
you can see what this page
looks like, but you will
not be able to add anything.
Annotation:
|
| |
#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. |
|
| |
Not at all. Based on the description of the idea, doing something like: |
|
| |
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... |
|
| |
Would do the same with the other service. |
|
| |
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. |
|
| |
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. |
|
| |
> 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. |
|
| |
I was a little worried from the title that this was going to be a
pitch for interactive porn with dedicated VR suites. |
|
| |
[Skewed], well one can certainly imagine a proper driver for that. |
|
| |
// 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], 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. |
|
| |
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]: 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. |
|
| |
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], 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. |
|
| |
//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. |
|
| |