Hello Pirmin,
thanks for posting your idea to the list.
I wonder, have you considered to implement the random service as a "Terminal" service that just produces a stream of random values? The benefit would be that such a server can be combined with the existing terminal infrastructure out of the box. For example, you could mount the random server's session in the VFS (via a <terminal> node) without any extra effort.
The rationale behind keeping the number of session interfaces as low as possible is given at the beginning of Chapter 4 "Components" in the documentation. Please excuse me blatantly citing myself ;-)
"The versatility of a component-based system does not come from the existence of many components alone. Even more important is the composability of components. Components can be combined only if their interfaces match. To maximize composability, the number of interfaces throughout the system should be as low as possible, and all interfaces should be largely orthogonal to each other. Section 4.5 reviews Genode’s common session interfaces."
So before starting to create a new interface, I always recommend to double check if the problem can be modeled via the existing interfaces. In most cases, this is possible. Sometimes, a combination of two interfaces does the trick. E.g., instead of equipping a session with the ability to request meta information directly from the server, it is often possible to let the server generate a report about its feature set (via the "Report" session) and let the client request this information as a ROM session. This out-of-band propagation of configuration data is much more flexible and better testable.
Cheers Norman