Re: [9front] rio wishlists

["Ethan Gardener" <eekee57@fastmail.fm>]

On Thu, Jan 23, 2020, at 9:23 PM, hiro wrote:
> does everybody understand what i mean with higher granularity
> namespace sharing? it might be non-obvious if you don't know the linux
> mount namespaces and their features.

I think so. With my idea, the sections of the namespace you could change with env vars are fixed at compile time. I mean there might be just one var for cons kbd mouse and draw, or there might be two, but that's about it. File namespacing allows all sorts of detail changes which the program/library authors may not have considered.

> i might be all wrong about this, but then i still would like to see a
> more generalized mechanism that is self-similar and orthogonal to
> everything else.
>

On Thu, Jan 23, 2020, at 10:42 PM, Julius Schmidt wrote:
> One mechanism would be turn the namespace into a tree of commands, which 
> can then be shared only partially.
> For instance, /dev could be a node in the tree which is shared among 
> most/all programs.

Sounds like what I intend for my Forth, but that's an entirely different concept. :)

> Another approach would be to give mount/bind commands a number indicating 
> priority, but I don't have a clear picture how that would work.

I don't think I quite understand either of these, but they inspired this "namespace priorities" idea: A process may have multiple namespaces, each with a different priority. Files are searched for in the highest-priority namespace first, then if they're not found, the next highest, etc. Rio would then pass two namespaces to each of its children, the global namespace it itself inherited as a low priority, and a high-priority private namespace with only its window-specific files. (This also seems to provide a better means of union mounting.

What happens if Rio inherits multiple namespaces in this scheme? Some options:
A: They could all look like one single namespace with rio unable to distinguish between them.
B: Priorities are numbers, the priorities of inherited namespaces are reduced.
C: Namespaces occupy a linked list. A namespace's priority is simply determined by its position in the list.

C is by far my favourite, linked lists are so powerful in this context. One of the biggest reasons I like Forth so much is the power given by the dictionary being a linked list.

B has the same problem as BASIC and APL with their line numbers and goto. :)

Both B and C have a little problem: What *exactly* is inherited by child processes? Are the numbers/is the list copied to each child, or can the child mess with the priorities of its parent? Grandparent? I suspect it would be enough to always copy the priorities, but I'm tired and need to stop thinking now.