9front - general discussion about 9front
 help / color / mirror / Atom feed
From: Willow Liquorice <willow@howhill.com>
To: 9front@9front.org
Subject: Re: [9front] Musings on web browsers and office applications
Date: Wed, 3 Apr 2024 21:42:28 +0100	[thread overview]
Message-ID: <7833cb39-ccb1-4f04-89ac-aaab6f25b80e@howhill.com> (raw)
In-Reply-To: <25847D39-F21B-463F-922E-E49E98CC6D85@gmail.com>

That's intriguing. What are those edge cases?

On 01/04/2024 10:17, Pavel Renev wrote:
> 1 апреля 2024 г. 02:13:38 UTC, Willow Liquorice <willow@howhill.com> пишет:
>> Hi,
>>
>> I've had Plan 9 on the brain for the past few months, and I read a pdffs in the recent conference proceedings, and I was wondering whether the principles in that paper could be applied to create a file server for something that uses the Document Object Model.
>>
>> You could then use the resulting directory tree in the core of a web browser (HTML) or office application (OpenDocument / Office Open XML).
>>
>> Just off the top of my head, maybe an example HTML document could be represented like this?
>>
>> html/
>>   !attrs/
>>     lang
>>       "en"
>>   01 head/
>>     01 title/
>>       01 text
>> 	"Test Page"
>>   02 body/
>>     01 p/
>>       !attrs/
>> 	class
>> 	  "dumb-stuff"
>>       01 text
>> 	"according to all known laws of aviation"
>>       02 comment
>> 	"why are you doing this"
>>       03 em/
>> 	01 text
>> 	  "there is no way that a bee should be able to fly"
>>       04 comment
>> 	"please stop"
>>
>> Consider "text in quotes" to be the contents of the files they appear under.
>>
>> I think the scheme above would work to identify attributes: the directory name would simply be an invalid tag name.
>>
>> What do you think? I don't know that much about 9P, so maybe there's a better way of expressing the order of elements in a directory tree than literally numbering the files and folders.
>>
>> 	- Willow
> 
> I tried something similar in the past and found out that
> 
> 1. it's slow: traversing file system involves a lot of syscalls and they are relatively expensive.
> 
> 2. it's not very useful: there are many edge cases that are pain to deal with in both server and client, and in practice attributes are way more important than actual tag hierarchy.
> 
> If I were writing a web-browser-as-a-fs today, I'd make a single file per "tab" with a specialized DOM query language console inside, plus similar files for CSS, JS and what else.

  reply	other threads:[~2024-04-03 20:43 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-01  2:13 Willow Liquorice
2024-04-01  9:17 ` Pavel Renev
2024-04-03 20:42   ` Willow Liquorice [this message]
2024-04-04  2:23     ` an2qzavok

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7833cb39-ccb1-4f04-89ac-aaab6f25b80e@howhill.com \
    --to=willow@howhill.com \
    --cc=9front@9front.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).