[Olsr-dev] GSoC 2010 - Olsrd questions for Freimap

[Stefano Pilla]

Hi,

Il giorno 06/ago/2010, alle ore 08:11, Henning Rogge <(spam-protected)> ha scritto:

> On Thu August 5 2010 13:16:10 Pilla Stefano wrote:
>>> Plugins cannot communicate with each other, so the httpinfo/txtinfo
>>> plugin is not aware of the internal state of the nameservice plugin.
>> 
>> This means that the only way to know if the nameservice plugin is active is
>> to check the existence of the latlon file....logically in the default
>> position....however this is not a good solution...any suggestions?
> You could add some kind of communication socket to the nameservice plugin, but 
> that would be a lot of effort for a small gain.
> 
> In the master branch we could convert the namespace plugin from the named pipe 
> to a telnet command, so multiple programs can query it, but that's not 
> possible this easy in the stable branch.
> 
>>> Maybe you could add the path/name of the latlon.js file into the
>>> configuration of your program instead of looking in the OLSRd conf for
>>> it ?
>> 
>> One of the main goal of this project is to completly remove config
>> file....when the application starts it should be able to discover olsrd
>> configuration ....
>> 
>> Also for this....any suggestions?
> I don't think this is possible. You need at least the port of a communication 
> socket, the path of a config file or some other settings.
> 
> Trying to read the config file of another program is (most times) a bad idea, 
> because the format can change in a way you don't suspect.
> 
>>>> For step 2, there is a way to discover the position of the olsr.conf
>>>> file?  If the user change the default value how I can check the new
>>>> position?
>>> 
>>> No, there is no easy way to do this.
>>> 
>>> Different distributions (debian, openwrt, native compile) place their
>>> configurations into different paths.
>> 
>> I have to do a "settings" panel in which users can specify the correct
>> paths....this means have a config file that can be modified from the
>> application at runtime... This solution can also resolve some of the
>> previous problems....what do you think?
> I think a small config file (maybe even with a web based admin page as you 
> suggested) is a good idea.

Thanks for the suggestions.

I'll try to add a communication socket to the nameservice plugin out of the GSoC program.

The nameservice plugin become a pre-requisite for my app.

Stefano Pilla

Sent from iPhone