Re: NETINFO cell spec ambiguities?

[Mike Perry <mikepery@xxxxxxxxxx>]

Thus spake Christian Seberino (chris@xxxxxxxxxxxx):

> 
> > On Tue, Jan 09, 2007 at 02:50:22PM -0500, chris@xxxxxxxxxxxx wrote:
> >> Sorry to be pedantic.  I don't want to make any mistakes...
> >>
> >> The NETINFO cell section of spec right *before* section 5
> >> refers reader to section 6.4 for details of NETINFO cell payload.
> >
> > Hi again Chris!
> >
> > NETINFO is from the draft for the next version of the Tor spec.  It
> > isn't in the current version.  There may have been some confusinon
> > about which version _was_ the current version: I've tried to clear
> > that up.
> 
> Hmmm. How soon will this NETINFO'd version be out?  I want to stay current
> but I also want to work with existing Tor network.  Perhaps best would be
> to target the bleeding edge spec for starters and later make the
> (hopefully few :) mods to make it operable in current network?

Actually, just from a development best practices standpoint I would
say exactly the opposite is a better idea. Target the minimum subset
of the existing protocol to get *something* working and build up from
there, making iterations with the smallest possible steps of
additional functionality to minimize debugging headaches. If you only
added a little since your last successful run, you know exactly what
broke.

Initially, "something" should be as simple as properly sending a
CREATE_FAST cell over a tls conn and getting and properly parsing the
CREATED_FAST response. Creating simple tests in a __main__ to automate
testing of each component each time is also a good idea, to make sure
your new stuff doesn't somehow break the old stuff in some unforseen
way.

This style of development is not only (much) faster, but hopefully
will help you more easily adjust to various ambiguities in the specs.

-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs