[Xorp-hackers] Omitting XrlDB from Router Manager

[Bruce Simpson]

Hi all,

    I'm still looking at the XRL replacement since I got back from 
holiday, which is why I've been mostly silent on lists.

    Something came up in analysis, which broadly relates to Ben Greear's 
work on reducing Router Manager startup times, etc. and some of the 
questions Li Zhao has been asking in other threads on this list.

@Ben: It would be interesting to know what difference omitting the XRLDB 
code makes to your Router Manager startup times.
 * The XRLDB seems to exist pretty much to validate what's in the 
template files and how the Router Manager uses them, although this is 
done completely at run time.
 * I wonder if disabling this code would make a difference to performance.
 * To do this, I'd hack rtrmgr/template_commands.cc, and comment out the 
calls to the XRLdb methods.
 * The rtrmgr/xrldb.cc is the only place in the whole system where the 
'*.xrls' files are parsed and used. They are used only to validate the 
syntax and structure of potential XRL method calls.
 * It would mean that there is no up-front validation of the XRLs, but 
in practice, this validation step is probably only of interest to people 
developing XORP, to catch problems with template files.
 * It's probably best folded under a compile-time #define for developer use.

@Li: You were looking for information on how XRLs are sent by the Router 
Manager to the XORP routing processes.
  * I've been looking at this code with a view to replacement.
  * This uses an indirect method call and lookup from the finder:// XRLs 
in the *.xrls files.
  * Implementing Thrift directly affects the Router Manager: in 
particular, the core functionality which configures processes by sending 
XRLs to them, in rtrmgr/template_commands.cc, class XrlAction.
   * In any event, because the Router Manager is trying to do method 
calls without an IDL or C++ stubs, using the textual Finder protocol, a 
different mechanism would be needed in Thrift.
    * The '*.tp' template files explicitly identify all argument and 
result types used when configuring a XORP process via an XRL. If these 
are correct, then additional validation shouldn't be needed.
    * Therefore: it's possible to construct a binary blob at runtime, 
using exactly the same techniques as in the clnt-gen Thrifted code 
generator.

cheers,
BMS