Version 2.0.0pre0

[Jan Bramkamp]

On 08/12/2016 18:19, Israel G. Lugo wrote:
>
> On 12/08/2016 04:42 PM, Martin Mares wrote:
>> Hello, world!\n
>>
>>> I think that we should expand static protocol to allow adding or deleting
>>> routes interactively. There are some problematic behavioral details in
>>> it; e.g., how we should handle interactive removal of a route from
>>> configuration. Should we have two independent sets of routes, one
>>> added/removed by reconfiguration, one interactively? Or should we allow
>>> to remove interactively one from configuration? If so, should it respawn
>>> during reconfiguration?
>> Maybe define a separate protocol which exports routes added/removed online?
>
> I really like this idea! A protocol called "interactive" or "runtime" or
> somesuch. It keeps the configuration clean, without having to complicate
> the static protocol, or having strange unintuituve behaviors. The
> "interactive" protocol would only have routes learned online, so its
> behavior is well defined. On bootup it has no routes, and during the
> lifetime of Bird, it will learn or forget routes manually through the
> CLI or other APIs. A few new CLI/API commands, to "add", "remove" and
> "clear". This makes the question of reconfiguration simple: it should
> not touch the "interactive" routes. If the user wants to clear them he
> will use the "clear" command at runtime.
>
> Regards,
> Israel

As long as each "record" is at most 512 bytes the protocol could just 
offer a named pipe to add new records. That would be crude because there 
is simple way to acknowledge writes, but trivial to interface with. A 
better way would be to replace the pipe with a unix domain sequential 
packet socket and simple protocol to report success/failure.