in rust book, chapter 4.1 and 4.1.4.1 you are stating the “Everything is an URL” principle. Some thoughts on that:
I find this idea great! In contrast to Unix “Everything is a file”, some things are not files, e.g. processes or hardware. Defining a protocol (“Scheme”) for this is a pretty interesting idea, it seems to better reflect reality.
How do you handle possible conflicts with your schemes to probably later introduced schemes? Let’s say some other widely-used service introduces a display: scheme? How about a redox prefix for schemes, like redox-display:?
With using URLs (which are strings, basically), don’t you give up on Rust’s concept of having errors found at compile time? In theory, anybody can create any (possibly invalid) URL. This is in contrast to Rust’s behavior trying to prevent possible runtime errors at compile time. Or did I just get it wrong and URLs are just used on ABI (syscall/IPC) level, but not exposed to (public) API?
We do not have a particular strategy for that. However, I don’t think it will be problem.[quote=“genodeftest, post:1, topic:105”]
With using URLs (which are strings, basically), don’t you give up on Rust’s concept of having errors found at compile time?
[/quote]
First of all: URLs are not just strings, they’re actually two strings: the scheme and the protocole. Secondly, any two arbitrarily formed UTF-8 string can form a URL, they do not have to be like paths.
Secondly (perhaps more important), you cannot go to supervisor mode (ring 0) in a strongly typed manner (without needing runtime checks anyways). This is the same reason for the Unix paths simply being strings.
Another related question: The rust book states that scheme resolution happens in the kernel. Is that correct?
If yes, why don’t you use shared memory so you can reduce the number of syscalls? Just have one shared memory library in userspace where all URL schemes are registered. Every application accessing schemes is compiled against it. This way you can get most URIs out of the kernel. Is that doable?