[olsr-dev] new ipc

[Thomas Lopatic]

[...]

> so let's think a bit further about a better ipc. for me a better ipc 
> would dump all the interesting data after a client connected or (for  a
> two-way protocol) after the client expressed it's interests. even  data

I would prefer to make this a pure request/response protocol. Let the
client request information and only then supply the information (and
only the requested information). If we supplied information that the
client is not interested in, we would nevertheless force the client to
be able to parse all the information that we supply and from that
extract the information that it is interested in.

So, suppose I wanted to write a Perl script that gets the OLSR routes
from olsrd. I'd like to send something like "get routes\r\n" to olsrd
and then I'd expect olsrd to give me the contents of its internal
routing table. And I would only have to teach my Perl script to parse
the routing information returned in response to my request. If I later
became additionally interested in the nodes neighbours, I'd implement a
second request in my Perl script, e.g. "get neighbours\r\n", and teach
the script how to parse the response.

> from plugins (like nameservice or powerinfo). then the better  ipc would

Yes. We should definitely allow plugins to register their own "get
X\r\n" requests and generated responses for them.

> send some sort of EOF and continue with subsequential  updates as long
> as the connection stays alive. a better ipc has some  sort of modular

I'd prefer to keep it simple and have the client poll olsrd. So, if we
want updated information, we'd simply re-send our request. In this way
it is up to the client to decide when it needs new information and which
information it is that it needs.

But I agree that we should keep it modular. Maybe a TCL-like command format:

  <plugin> <command> <argument> [<argument> [<argument> [...]]]

<plugin> would identify the plugin to which the command and the
arguments are to be forwarded, e.g.

  nameservice resolve 104.1.2.3

or

  olsrd get routes

So, each plugin could register a request parser. The nameservice plugin
would do so under the identifier "nameservice", etc.

> protocol and the dataformat is human readable. this  makes it suitable
> for scripting. kismet (1) is somehow related to  olsrd regarding the

Yes, suitable for scripting and debugging. Fully agreed.

> architecture (client, server, plugins) and has a  very good ipc protocol
> in my opinion.

Interesting. I wasn't aware of this. I'll look into this during the next
couple of days.

> your toughts?

Let's keep going... :-)

-Thomas