Okay , let's try to understand why, but first - I spent a very lot of time to design and implement IDL for this purposes without any applicable results - that's my fail first, and that's an idea fail second.
Usually you have a simple IDL case: take the message, parse it, call the server function, serialize it and reply. It's common for client-server architecture widely used, and yes, there are many already implemented IDLs for this simple case. Most of IDLs covers this needs.
You can told me about L4 IDL - you are welcome, I didn't see any serios developed with L4 IDL, and I can told you - it will suck.
My approach was more complex.
In case of Jari OS services you need more than receive - call - reply cycle. Request might be postponed, or changed and forwarded.
In real system (not like L4 ping-pong demos), to resolve resource by the name (symlinks and files) you always need to forward it, because symlink and file might be located on different servers. Also, on real system, blocking of server threads is a quite poor idea.
IDL concept was very simple before I've added postponed and forwarded messages, but it wan't so fatally, to get away with this idea.
The next problem was faced later, like time-bomb, it was message modification.
Finally I've got something huge, and not flexible and scalable.
IDL implementation with support of this features are not simply than some RPC interface.
Well, at this point I decide to stop it. I spent something about 1 year to design, research, test and try it - and got the ugly solution.
However, in Jari OS you will be able to use IDL with this features, but it will not used in the base system.
IDL research implementation here - http://jarios.org/gitweb/?p=jari_os.git;a=summary , checkout idlc branch.
No comments:
Post a Comment