Why IDL fail, or, sometimes you need to fail first, to rise next

IDL for microkernel multiservice system is fail. No, not just because it wasn't implemented, going deeper - it's implemented.

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.

Protocol points: is IDL a mixture for headache?

There are a problem with a distributed message passing based system - it's a protocol.

It's a very bad to implement all protocol stuff manually, you will spent a many time on the

very simple, but annoying job, and you will create s new bugs, a lot of ugly code and so on ...

In the real distributed systems is many kind of intercommunication exist, I mean that you need some protocol for system-wide bus, some other protocol for services of the group A and some other for the other groups. Usually you will has a tons of different protocols and it will be a problem to create new one or update/modify existing.

I found two ways to fix this headache and one of this way is widely used in the systems of such kind, it's IDL. It may be ORB/CORBA like interface description language and usually is it.

Mainly, you need to pass some typed message and get some typed response to this message, and this problem is finely solved in CORBA-like IDLs, in contrast if you are working in the complex distributed system you need to have many indirect message passing system that will impact to your protocol.

In the system of such kind you also need to determine the message sender, his priority, and his level of the access or, more widely, what the access rights has this message. While you are going deeper you will understand that for some complex systems (like distributed system for transport queue management) that should works with determined time range you will need something like QoS (yep, I mean here quality of service). There impacts are going to your protocol.

Now, imagine that you have a CORBA-like IDL and you need extended option described above ...

You will describe some proto on IDL, and you will implement QoS, protocol for access inheritance manually ... In this case it's a good point to think where is headache located ?

The other way - it's a runtime solution for passing arguments via messages it will has the same disadvantages, but will be simply in implementation.

Well, the question is open - where is a mixture for headache with distributed message passing ?