[Xorp-hackers] XORP documentation wiki is online.

[Matthew Jakeman]

On Tue, 2011-03-15 at 09:23 -0700, Ben Greear wrote:
> On 03/15/2011 05:58 AM, Matthew Jakeman wrote:
> > On Mon, 2011-03-14 at 21:04 -0700, Ben Greear wrote:
> >> On 03/14/2011 03:45 PM, Matthew Jakeman wrote:
> >>> Hi Ben, all,
> >>>
> >>> This is great. I have just had a look through the new documentation on
> >>> the wiki and there are some significant updates on there that should
> >>> make peoples introduction to XORP a lot easier. In particular the
> >>> updated documentation for writing a process that has updated the old
> >>> Makefile information to the latest scons processes (among other things).
> >>> This will be especially useful to people who haven't used XORP before as
> >>> it was one thing I struggled with a bit when first using XORP.
> >>>
> >>> Huge thanks to both yourself and Pierre for this. Myself and Pierre are
> >>> both working on the ECODE project from which this has come about and
> >>> it's good to see that it has already pushed something back into the
> >>> community.
> >>
> >> The documentation help is very useful and very welcome.
> >>
> >> I am also curious about the state of your xorp modifications.  Are
> >> they still scheduled to be publicly released?  If so, I'd like
> >> to try to figure out how to make them part of the official
> >> xorp tree.  Perhaps somewhere in the contrib/ directory if
> >> it's not general purpose code.
> >>
> >
> > We are still working on our implementation and are hoping to release the
> > source code into the public domain at some point down the line.
> >
> > One problem we have is that because the async stuff Steven has
> > implemented was not originally in XORP we have implemented our prototype
> > using the original XORP code. This means that if we wanted to fully
> > integrate it into XORP properly, we will have the issue of porting the
> > code to the new style of coding.
> 
> This is exactly why you should merge your code early and often:
> Maybe he could have used your fixes, or vice versa..and either way,
> both of you might be better off.

The problem was that we (Steve and myself work at the same institution)
weren't sure how long the changes he has recently done to implement the
async stuff were going to take, yet we pretty much knew how long it
would take to implement the ECODE work the other way. Therefore it has
been implemented within our own XORP tree to a working standard to
facilitate quicker implementation of other factors across the board.
Unfortunately this also means that we have two source trees but we had
no choice but to proceed in this manner in case the async implementation
took a lot longer than expected.

> 
> > We will be looking at this further down the line and depending on the
> > project time constraints, we will see if we can integrate it in a nice
> > manner within the XORP code tree as I believe it would be a nice
> > addition to have in there. Obviously it would be better overall for us
> > to release the code within XORP rather than releasing our branch
> > separately.
> >
> > We will be in touch a bit further down the line and let you know how we
> > progress with these issues.
> 
> About the only guarantee is that the longer you wait, the more difficult
> the merge will be.  But, it's not my decision, and I hope your plans work
> out fine regardless.

The merge shouldn't change in complexity now, as long as we export the
same API from the ECODE part. I had a chat with Steve today and he
thinks that the integration of the async and ECODE work shouldn't
present too much of a challenge so hopefully this will get done in the
near future. We definitely want to work towards integrating the ECODE
work into XORP before our project finishes...

Cheers
Matt

> 
> Thanks,
> Ben
>