[HN Gopher] File Systems: The Original Hypermedia
___________________________________________________________________
File Systems: The Original Hypermedia
Author : pilgrim0
Score : 24 points
Date : 2025-01-21 00:16 UTC (1 days ago)
(HTM) web link (jon.work)
(TXT) w3m dump (jon.work)
| p_ing wrote:
| I struggle to parse this with every paragraph surrounded by a
| border. It feels unnatural and extremely distracting.
|
| To the author's take of using a file system as an interconnected
| 'web', we have networked file systems today, typically clustered
| though.
|
| We've also had the _concept_ of a media-rich file system, like
| WinFS [as an overlay to NTFS], which was dead before it was alive
| due to the WWW.
|
| Networking file systems is _complex_. All vendors would need to
| agree to a common export model on top of their preferred file
| systems. Or users would need a specialized partition/overlay
| developed just for this purpose.
|
| FSes are great, but they're not fit for WWW. Without a control
| plane, they lack any tooling that makes the WWW better --
| redirection, access control, programmatic execution of content
| (ASP.NET, PHP, CGI ...), etc.
|
| Ultimately this would be a complex solution. Just like many don't
| simply "open up" their web server to any and all traffic to any
| and all content, a file system would need to be carefully
| partitioned the same.
|
| The time for file systems as the vehicle for WWW content is long
| since past. We have better ways to do things, better caching
| mechanisms, better performance [through CDNs], better security
| mechanisms, and so on.
|
| ...not to mention, I certainly don't want to open my personal
| computer's file system up to the Internet.
|
| There would have to be a big leap in evolution of file systems
| across all major operating systems for the author's dream to come
| true. I would certainly be excited to see it, but we're talking
| about allocating _talented_ developers to create a new file
| system and certainly an open source file system. Like many file
| systems, it would take years to become a trusted file system to
| host any content of value.
|
| In the mean time, the author can always investigate WebDAV.
| Slower than dog shit, but it's available with every major web
| server.
| pilgrim0 wrote:
| Sorry for the poor experience with the current design, still
| experimenting.
|
| I cannot disagree with you, you're on point on everything when
| considering the file system as an OS component.
|
| But if we entertain the thought of file system as a document
| model, or as a transactional data structure, it should come
| naturally that we can piggyback on the modern infrastructure,
| at the application level, to achieve the desired qualities.
|
| This very website is an experiment on how this could be done.
| The main takeaway with my research is that we have much to gain
| if we leave presentation and layout concerns out of hypermedia
| documents, letting the client software decide on it, like we do
| with our editors and IDEs, choosing the theme and font we like,
| the information is the same no matter. To abandon the fetishism
| inherited from print media and to transact pure data is to make
| the web democratic. That's precisely the recipe used by all
| social networks: standardized, systemic presentation of
| schematic payloads following a given ontological model. We need
| only to copy them with an open model
| p_ing wrote:
| > Sorry for the poor experience with the current design,
| still experimenting.
|
| Never stop experimenting.
|
| > file system as a document model, or as a transactional data
| structure, it should come naturally that we can piggyback on
| the modern infrastructure, at the application level, to
| achieve the desired qualities.
|
| I'm having a little difficulty groking what you're trying to
| say, here. Can you explain it like I'm stupid? My mind
| immediately bounced to SQL storing binary data or a document
| DB of some sort.
|
| > if we leave presentation and layout concerns out of
| hypermedia documents, letting the client software decide on
| it
|
| Every browser engine does this today. Every engine developer
| has their own idea of how a standard should be implemented.
| Granted, this isn't end-user choice, which is probably what
| you're after. Well, sorta, you have some customization of
| fonts and [link] colors.
|
| > To abandon the fetishism inherited from print media and to
| transact pure data is to make the web democratic.
|
| It sounds like you would like some simple scheme that
| provided you the text and binary data (images) of the website
| which allowed you to manipulate them into the "newspaper"
| layout of your choice. Am I getting that correct?
| pilgrim0 wrote:
| You cannot fully leave presentation concerns out of
| browsers. Layout and decoration is an integral part of
| authoring, it's supported at the markup level. HTML and
| friends are practically rendering instructions at this
| point, as if a PostScript for screens. Worse, this has a
| double edge, for instance, not always what should be a
| single paragraph of text comes as a single <p> tag, because
| the mere availability of styling leads people to author ad-
| hoc structures, since they know it could always be visually
| reconciled.
|
| What I'm proposing with the research is a data structure
| transmitted as text. This text payload is the equivalent of
| a file system volume or tree. Each line in this payload is
| the equivalent of a file. It's only a semiotic analogy to
| file systems.
|
| Given this is such a trivial structure, it's easy to
| develop multiple rendering approaches that maintain an
| isomorphism between the text representation and graphical
| representation. It does not transmit layout information,
| the syntax itself is the higher-order layout.
|
| You might wanna checkout the source of this article by
| appending index.fifo.txt to its URL.
| pwg wrote:
| > Sorry for the poor experience with the current design,
| still experimenting.
|
| It also is simply a blank page when browsed with UBlockOrigin
| blocking all the java script from executing.
| mickael-kerjean wrote:
| > WebDAV. Slower than dog shit, but it's available with every
| major web server.
|
| You lost me there. WebDAV is nothing more than HTTP calls with
| some XML data with a slightly different syntax than the S3 API.
| There is no fundamental stuff in the spec that command the
| protocol to be "slower than dog shit" as a file transfer
| protocol. Please prove me wrong with another argument than:
| "the particular server implementation I tried was dog shit"
| moritz wrote:
| > You would create and manage content directly from the file
| explorer application, in the most natural way possible. This
| version of the web wouldn't require users to learn advanced
| computer skills in order to participate.
|
| My students at university (Gen Z) have no concept of the "file
| system".
| pilgrim0 wrote:
| Inline, ordered multimedia is the backbone of all consumer
| information systems. So your students have internalized the the
| archetypal equivalent of file systems through a different
| vocabulary, such as tweet (for files) and threads (for
| directories)
| dialup_sounds wrote:
| That's not even a generational thing. People have been (e.g.)
| saving everything to the desktop for as long as there have been
| desktops. "Managing files" has always been a subsidiary task to
| the things people wanted to use computers for.
| xnx wrote:
| A usable equivalent of the file system is sorely missing from the
| web. Every email address should come with a place to publically
| share files. It could be as easy as https://user@emaildomain.com/
| mongol wrote:
| That is an http basic auth URL.
| Borg3 wrote:
| O really? It seems people forgot about userdir.path (or
| similar). So user can expose whatever he wants via:
| https://emaildomain.com/~user/
| xnx wrote:
| Exactly. This convention is virtually non existent on the web
| in 2025.
| recursivedoubts wrote:
| _> if we always had hypermedia with directories and files, why
| hasn 't the web evolved into a mesh of interconnected file
| systems?_
|
| It kind of has. URLs have the notion of paths, which are
| obviously strongly associated with the notion of file system
| hierarchies. People sometimes (sometimes accidentally) put their
| file systems directly on the web, see DirectoryIndex in apache
| for example.
|
| _> Why isn 't a website just a remote directory on someone's
| computer that we can explore via a file browser?_
|
| Well now we are getting into the meat of it. To be a hypermedia
| requires the presence of hypermedia controls in a media.
| Hypermedia controls can be as simple as links, but the web
| introduced more sophisticated controls such as forms, and allowed
| HTML authors to specify more significant interactions beyond
| click-to-link.
|
| IMO the uniform interface is the most interesting aspect of
| hypermedia, and that really emerged post Web. I like the authors
| concept of a file explorer enhanced with hypermedia ideas though
| and would be interested to see more details on it.
___________________________________________________________________
(page generated 2025-01-22 23:01 UTC)