Protocol questions

[Aaron Stone]

On Sat, 2008-03-01 at 12:01 -0800, Dustin Sallings wrote:
> On Mar 1, 2008, at 11:49, Aaron Stone wrote:
> 
> > Hah, duh. Thanks. Maybe then one of my earlier points, that it's ok to
> > have separate ports for binary and text (in fact, perhaps requires),  
> > but
> > make it clear that it's because they're pretty much different  
> > protocols,
> > with different rules on how to figure out capabilities.
> 
> 
> 	People have been asking for reasons, and as the protocols were  
> defined, the only reason has been ``because I don't want to do it.''

There's usually a good reason why someone is holding out, and I respect
that a lot. Plus you're writing the code :-)

> 	What's happening here is the protocols are changing shape so that  
> that's no longer true.
> 
> 	Maybe we should stop calling it ``the binary protocol'' and start  
> calling it ``perl 6.''  :)
> 
> 	I know we want to get it absolutely perfect, but it's kind of got  
> this ``never going to happen'' vibe now.  I pushed out my code for the  
> first version on my daughter's 12th birthday last July.  If she turns  
> 13 without this product having shipped, what will she think of me?

Let's start identifying the blockers and the nice-to-haves. If we thing
we're going to have problems with different protocol rules between
binary and text such that cohabiting on the same port causes brain
damage and hackery to spread between the two, it is a killer. We have to
block on figuring out what goes on the same port and what doesn't.

[ And while I +1'd the email yesterday about how we should be able to
handle binary and text commands on the same port, today's discussion
makes me realize that it's a very bad idea. We should be able to do both
TCP and UDP on the same ports as their respective text/binary, though? ]

If we get a mostly-working protocol out the door, and find some
problems, but forget to clearly specify rules for new protocol versions,
that's a killer. We have to block on making sure we get the protocol
version stuff right the first time.

Hang in there?

> 	That said, we could reserve an opaque value to mean ``untagged'' and  
> have it be a sort of out-of-band response a la IMAP.  As long as it's  
> ignorable, it shouldn't be a huge problem.

Neat idea. I could see that working.

Aaron