[Olsr-dev] quick and stupid version on txtinfo plugin

[Hans-Christoph Steiner]

On May 25, 2012, at 10:52 AM, Henning Rogge wrote:

> On Fri, May 25, 2012 at 3:01 PM, Ferry Huberts <(spam-protected)> wrote:
>> So no reason we can't separate that from the routing daemon. :-)
>> 
>> I think we need to work towards a more scaleable, loosely coupled system.
>> 
>> 
>> At one time I've even considered creating a special plugin, a message
>> forwarder. For all tasks that do not involve interfacing with the olsrd core
>> this new plugin would enable these tasks to be separate processes.
>> I still think that's a nice idea.
> 
> If you want to do this, just use the telnet server and the JSON output
> to export the data. I am not sure if I am a fan of a distributed
> structure like you describe it, because it can be a pain to keep in
> sync when you change one part.
> 
> But I am thinking about the idea that plugins might call code from
> other plugins at the moment.

This would probably fit pretty well into the classic Model-View-Controller paradigm, so as long as olsrd has a way to dump all of its info, and accept commands from other things (via UNIX sockets, network sockets, etc.)  then it would be the Model, and people could build their own Views and Controllers as they see fit.

jsoninfo plugin is structured with this kind of thing in might, but its currently only delivering info, not accepting commands.  One thing I'm currently thinking about is where to draw the line on the information jsoninfo delivers.  For example, should it also deliver the ESSID, channel, BSSID, and MAC address?  I think it should deliver all relevant info so that is can be the one source of node info needed for management and test interfaces.

Since this gets into very trackable information (MAC address, etc.) I am thinking there needs to be some kind of access control as well.  Probably just IP based for now, but ultimately, there probably should be an HTTPS option.

.hc