we need to extend the existing RML function to handle the
subsequent setting of the route to the proc itself. In the current
dpm, we automatically assume that the route will be to a different
job family, and hence send the routing info to the HNP. However,
this may not be true - e.g., afte
No religious fervor on my end either :-)
I have in my notes from the July meeting some thoughts/talk about
needing a function like this, but (probably just in notes from
thinking) some question as to the best place to put it. The dpm does
create the port string, so having a "route_to_port"
Ralph,
I just split the existing static function from inside the dpm and
exposed it to the outside world. The idea is that the dpm create the
(opaque) port strings and therefore nows how they are supposed to be
formated. So he is responsible for parsing them. Second, I split the
parsing a
Yo Aurelien
Regarding the dpm including a "route_to_port" API. This actually is
pretty close to being an exact duplicate of an already existing
function in the RML that takes a URI as it's input, parses it to
separate the proc name and the contact info, sets the contact info
into the OOB,