6 ms·

An attempt is being made to reduce everything to: interface UniversalInterface { fun open(…) fun read(…) fun write(…) fun c

An attempt is being made to reduce everything to: interface UniversalInterface { fun open(…) fun read(…) fun write(…) fun close(…) } If you went to a software engineering design review meeting, proposing that several different kinds of objects representing everything from files, network sockets, to arbitrary devices should all use the interface above, you’d be laughed out of the room. Ultimately, when someone does end up implementing something like the above as the sole interface for some major component, it’ll result in libraries that return a wrapping object with a more useable and pleasing interface that abstracts away the ugliness of using UniversalInterface to interact with said component. I see two ways forward with this. Either: (a) present the option of using UniversalInterface to interact with X object, in addition to interface that’s much more idiomatic and closer to how X object actually behaves. Or, (b) come up with an alternative universal (or flexible) object interaction interface that’s much more flexible than UniversalInterface.

Someone 3y ago
> Either: (a) present the option of using UniversalInterface to interact with X object, in addition to interface that’s much more idiomatic and closer to how X object actually behaves. > Or, (b) come up with an alternative universal (or flexible) object interaction interface that’s much more flexible than UniversalInterface. That’s, basically, what COM/Corba/… are. There, UniversalInterface has an additional call “If you are a Foo, give me your Foo interface”, with Foo as an argument to that call.
- Spivak 3y ago
  And dbus as well on Linux. I think that that style is much better than everything is a file. Everything is a typed object.
  - winter_blue 3y ago
    > Everything is a typed object. That's really good. The fact that the file interface just gives you a string of bytes, with no concept of structure or type safety in the interface itself is a major flow of it. Type safety is immensely valuable.
3cats-in-a-coat 3y ago
> If you went to a software engineering design review meeting, proposing that several different kinds of objects representing everything from files, network sockets, to arbitrary devices should all use the interface above, you’d be laughed out of the room. You're describing a meeting in which people seem unaware of the purpose of uniform interfaces. Not sure we could call such a meeting "engineering design" meeting, because engineers tend to know better. If I went up and proposed the same interface for all cables, displays, mice, keyboards, speakers, hard drives, phones... and called it USB, would I also be laughed out of the room? There's no benefit to reinventing open/close/read/write in 50 different ways. The goal is to do it once, and then build more complex interfaces on top of it. That is, unless you're paid by the number of lines of code you write.
- codedokode 3y ago
  > The goal is to do it once There is an universal interface, it is called "system call". Rather than build unnecessary layer on top of it, improve the syscalls if you don't like them, and get rid of ioctls, /proc, /sys and other pseudo-syscall abstractions.
gpderetta 3y ago
A file descriptor is equivalent to the Object universal base class in many OO languages [1] and represents an handle to an OS resource. Now in UNIX you can have anonymous [2] resources, but in the Plan9 model most resources have a name and you can get an handle to it via open(<resource-name>). Hence open is not part of your UniversalInterface, but it is a way to obtain a reference to it. It seems reasonable to have a generic way to dispose of an UniversalInterface (hence close). read/write are simply a generic ways to send and receive messages from UniversalInterface, not unlike a dynamically typed object. Ideally you would do a checked down cast to your actual interface [3], but this was designed to work with C so you have to make do. [1] I don't subscribe to the Everything is an Object in the OO sense, but having a common base class for most OS resources seem a reasonable solution. [2] or at the very least there isn't always a cross-resource-type namespace. [3] Not unlike COM QueryInterface, and in fact UniversalInterface is equivalent to IUnknown
packetlost 3y ago
That is quite literally how Kubernetes works at large, which Plan 9 is to Unix as Kubernetes is to Linux, sort of. When the system is built from the ground up to be distributed across heterogeneous systems, you basically must build higher order protocols on top of really really simple ones. It's not that opening a byte-stream socket is the best interface for everything, it's that it's the lowest common denominator that everything can agree on no matter what. This is very obviously an acceptable solution because the whole world runs on TCP.
barrkel 3y ago
That's not far from the CRUD of a database, or POST/GET/PUT/DELETE of HTTP. It's also not far from what you'd expect at the transport layer of an RPC / IPC mechanism. The metadata around files - ownership, permissions, creation time - apply to a lot more than files. I don't really see it being laughed out of the room.
naasking 3y ago
> you’d be laughed out of the room Doubtful. Why are the main paradigms? Everything is an object Everything is a function Everything is a resource (REST) Uniform interfaces are common for good reason: you gain a lot of flexibility for redirection, introspection and policy control.
GoblinSlayer 3y ago
>Ultimately, when someone does end up implementing something like the above as the sole interface for some major component, it’ll result in libraries that return a wrapping object with a more useable and pleasing interface that abstracts away the ugliness of using UniversalInterface to interact with said component. Yes? All interfaces do that, especially system interfaces. It's the whole purpose of interface - to provide implementation logic in a usable form. Try to call the kernel by hand and see the difference.

Someone 3y ago

> Either: (a) present the option of using UniversalInterface to interact with X object, in addition to interface that’s much more idiomatic and closer to how X object actually behaves. > Or, (b) come up with an alternative universal (or flexible) object interaction interface that’s much more flexible than UniversalInterface. That’s, basically, what COM/Corba/… are. There, UniversalInterface has an additional call “If you are a Foo, give me your Foo interface”, with Foo as an argument to that call.

Spivak 3y ago
And dbus as well on Linux. I think that that style is much better than everything is a file. Everything is a typed object.
- winter_blue 3y ago
  > Everything is a typed object. That's really good. The fact that the file interface just gives you a string of bytes, with no concept of structure or type safety in the interface itself is a major flow of it. Type safety is immensely valuable.

3cats-in-a-coat 3y ago

> If you went to a software engineering design review meeting, proposing that several different kinds of objects representing everything from files, network sockets, to arbitrary devices should all use the interface above, you’d be laughed out of the room. You're describing a meeting in which people seem unaware of the purpose of uniform interfaces. Not sure we could call such a meeting "engineering design" meeting, because engineers tend to know better. If I went up and proposed the same interface for all cables, displays, mice, keyboards, speakers, hard drives, phones... and called it USB, would I also be laughed out of the room? There's no benefit to reinventing open/close/read/write in 50 different ways. The goal is to do it once, and then build more complex interfaces on top of it. That is, unless you're paid by the number of lines of code you write.

codedokode 3y ago
> The goal is to do it once There is an universal interface, it is called "system call". Rather than build unnecessary layer on top of it, improve the syscalls if you don't like them, and get rid of ioctls, /proc, /sys and other pseudo-syscall abstractions.

gpderetta 3y ago

A file descriptor is equivalent to the Object universal base class in many OO languages [1] and represents an handle to an OS resource. Now in UNIX you can have anonymous [2] resources, but in the Plan9 model most resources have a name and you can get an handle to it via open(<resource-name>). Hence open is not part of your UniversalInterface, but it is a way to obtain a reference to it. It seems reasonable to have a generic way to dispose of an UniversalInterface (hence close). read/write are simply a generic ways to send and receive messages from UniversalInterface, not unlike a dynamically typed object. Ideally you would do a checked down cast to your actual interface [3], but this was designed to work with C so you have to make do. [1] I don't subscribe to the Everything is an Object in the OO sense, but having a common base class for most OS resources seem a reasonable solution. [2] or at the very least there isn't always a cross-resource-type namespace. [3] Not unlike COM QueryInterface, and in fact UniversalInterface is equivalent to IUnknown

packetlost 3y ago

That is quite literally how Kubernetes works at large, which Plan 9 is to Unix as Kubernetes is to Linux, sort of. When the system is built from the ground up to be distributed across heterogeneous systems, you basically must build higher order protocols on top of really really simple ones. It's not that opening a byte-stream socket is the best interface for everything, it's that it's the lowest common denominator that everything can agree on no matter what. This is very obviously an acceptable solution because the whole world runs on TCP.

barrkel 3y ago

That's not far from the CRUD of a database, or POST/GET/PUT/DELETE of HTTP. It's also not far from what you'd expect at the transport layer of an RPC / IPC mechanism. The metadata around files - ownership, permissions, creation time - apply to a lot more than files. I don't really see it being laughed out of the room.

naasking 3y ago

> you’d be laughed out of the room Doubtful. Why are the main paradigms? Everything is an object Everything is a function Everything is a resource (REST) Uniform interfaces are common for good reason: you gain a lot of flexibility for redirection, introspection and policy control.

GoblinSlayer 3y ago

>Ultimately, when someone does end up implementing something like the above as the sole interface for some major component, it’ll result in libraries that return a wrapping object with a more useable and pleasing interface that abstracts away the ugliness of using UniversalInterface to interact with said component. Yes? All interfaces do that, especially system interfaces. It's the whole purpose of interface - to provide implementation logic in a usable form. Try to call the kernel by hand and see the difference.