[9front] Musings on web browsers and office applications

[9front] Musings on web browsers and office applications

[Willow Liquorice]

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

Re: [9front] Musings on web browsers and office applications

[Pavel Renev]

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.

Re: [9front] Musings on web browsers and office applications

[Willow Liquorice]

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.

Re: [9front] Musings on web browsers and office applications

[an2qzavok]

> That's intriguing. What are those edge cases?
My memory of HTML standard is fading...

Main issue is all the elements that have extra state associated with them.
Sometimes data needs to be fetched from outside (img, link), fetching can be 
non-trivial and controled by client software (source) or user (audio, video).
Sometimes data is provided by user (text input fields, radio buttons), or 
generated by scripts (canvas)
Very often data needs to be processed before use (decoding videos, resizing 
images)
iframe is nasty in particular because it's not just static data but another 
whole DOM instance.

Another issue is various metadata, for example style properties. Those need to 
be derived from multiple sources (some of them external, i.e. linked css)  and 
can be changed by scripts and need to be recomputed.

And a real showstopper is dynamic/OOP nature of the DOM, where nodes have many 
methods depending on their type (around 12 of them) and can be created, 
destroyed and rearranged right under user's feet.

It's hard to draw a line on where handling all of this belongs, fileserver or 
it's client. The more work we push on the client, the less useful server 
becomes, but doing things in server ruins all our hopes of having nice and 
clean file structure and doesn't make client's work any easier, only different 
kind of complicated.

(Huh, I guess these are not really edge cases, these are meat and bones of 
HTML now. Sorry for the confusion.)