[Xorp-hackers] More on Thrift and 3rd party Java interop.

[Bruce Simpson]

At this point, I'm also trying to consider what other participants on 
this list have raised as desirable features.

 1. Java support, specifically JNI.

    I'm not 100% sure what the original submitter meant. Trying to wrap 
the existing XORP router code as a set of JNI methods is probably a 
futile exercise, given that JNI code generally needs to be completely 
thread safe.

    However, assuming that the objective is just to interact with the 
XORP processes using RPC, or even implement router processes in Java, 
that would certainly be possible with the Thrift changes.

    I just skimmed what's available. In Java, the use of blocking I/O 
operations generally isn't an issue, as threads are somewhat cheaper, 
and preferred in that language; it should be possible to just re-use the 
existing Java client libraries which ship with Thrift. For client 
processes, which just interact with the router components at a simple 
level, this is just fine.

    For implementing routing processes in Java, we have a whole other 
set of issues.
    In libfeaclient, libxipc, we've got a set of common operations in a 
framework for interacting with other components within XORP itself, and 
which could be candidates for invocation through a language-neutral 
interface.

    Wrapping in this way would be necessary, to avoid reimplementing all 
the logic. Both libfeaclient, and libxipc, rely on the XORP EventLoop as 
a means of realizing an event-driven programming framework.  Thread 
safety of the APIs would be an issue here; some sort of service thread 
would be necessary to wrap them as components safely.

    I don't plan to look at this further as part of the current effort. 
It does require further work to support such use, and this is really out 
of scope for what's possible in the near future.

 2. XML-RPC.

    Given that implementing Thrift would let an object scripting 
language talk directly to XORP processes, and that many of them have 
excellent XML support, it's probably better to let that be the 
translation mechanism. XML-RPC doesn't really have a place in the 
embeddable router core itself, for performance reasons; although, this 
guideline could be broken, see below re shared memory.

 3. Bringing back SNMP support.

    In current SVN XORP, I've pulled SNMP support, mostly because it 
doesn't slot into the framework well at all, and doesn't provide much of 
the SNMP functionality anyway.
    What I've said so far holds fine for incremental / fine-grained 
control data. In situations where we potentially need to ship an entire 
default-free-zone routing table across process boundaries, we're 
probably talking about a good case for shared memory.

    Certainly, the fact that we have a lot of critical data, locked up 
in the address space of a process, which we can't otherwise get at, has 
meant we've had to bend the rules in the past. There are no 100% clean 
ways of dealing with it.

cheers,
BMS