Ben Greear wrote: > Any reason we can't move OLSR out of contrib and into the main directory > so that we can build it with scons? In my testing OLSR was as stable as > any other protocol, and if someone doesn't want to use it, they > simply don't add it to their xorp config file, eh? >
I'd rather we didn't move it out of contrib/ until well after 1.7. The OLSR implementation in XORP is based on a reasonably strict interpretation of the RFC, and doesn't have support for IPv6 or the ETX extensions, which are pretty much essential now for folk deploying OLSR in the field. I would consider it an unfinished work in progress. It became clear, at that point in time, that there were just too many other issues in the existing architecture to deliver what the original client wanted on time and within budget. I understand people are certainly using it and trying to base work off it. That's great, and I'm pleased folk have found what's been produced to date, useful in some way. But I'd rather we didn't create the impression that it's mainline or supported code, until the story with extensibility is dealt with, and that's a risk in moving it into the top of the tree. There are other problems to be solved first, and de-contrib'ing it at this point in time seems like a distraction from the primary goals. So +1 vote for 'come back to this later on'. P.S. I'm not 100% happy with OLSR, as you can probably tell. There are a few places where it could borrow from Joe Macker's code for more efficient MPR set computation, and Boost might well make that easier. There's a list of stuff in contrib/olsr README and NOTES. Note well the comment about BufferedAsyncReader eating 256KB for *every* STCP session in XRL!! _______________________________________________ Xorp-hackers mailing list [email protected] http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
