Hi all,
I'm working on the SPDY/3 implementation as one of necko's Q2 goals.
This post talks about how to manage the evolution of the protocol.
We can expect the protocol to continue to iterate during
standardization. Working with draft protocols is part of the IETF
process - we want to get some experience with the interim products to
inform the final result. At the same time, we want to get old revisions
off the network so they don't become defacto standards. (thank goodness
for silent updates). I can't speak for google, but my understanding is
they feel the same way.
During this process (which given IETF history can take years), I am
advocating that we support two revs of the protocol at any given time:
the current rev (N) and N-1. That gives server side implementations
significant windows (probably at least half a year) to update. Should
they fail to do so we just fall back to HTTP/1 without any round trip
penalties.
Whenever I talk to other early implementors I discuss this strategy for
keeping progress moving and so far everybody (both client and server) is
buying in to the general concept of retiring things with a few months of
overlap and not using flag days - using HTTP/1 as the fallback. So
that's good.
That means when I implement v3 we will support {v2, v3}, and when we do
v4 we will support {v3, v4}, etc..
As for our code, I am planning to deal with it a little differently than
the HTTP/1.{0,1} split even though the differences are probably of a
similar magnitude. The 1.0 vs 1.1 split is handled directly in the HTTP
code as a series of conditionals and state variables.. due to the more
rapid evolution of spdy at this early stage, I want to split N and N-1
up into two different classes with N being created from a clone of N-1
and then modified locally. I'll then implement an abstract SpdySession
which can create either version of a concrete implementation and provide
a more stable interface for the connection manager etc to use.. This
results in code duplication but it also lets rev N-1 stay stable and
regression free as N gets worked over and keeps each one a little
simpler than the aggregate would be.
Its likely there will still be a little version conditional logic in
places other than directly the spdy code (though that hasn't come up yet
in my work), but it should be kept to a minimum.
I have a wip patch that does this and so far it has gone smoothly.
this is mostly fyi, but feedback and/or constructive comments are
welcome at this stage!
-P
_______________________________________________
dev-tech-network mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-network
