If the answers are in the slides, forgive me - using the iPad the Google slide software breaks the back button and is too annoying to read beyond a few slide pages. Debugging and implementing older protocols seem to be easier, as they were text based.
Many do, yes.
> Will there be v2-only servers in near future?
Yes.
> Debugging and implementing older protocols seem to be easier, as they were text based.
Implementing text protocols seems to be easier, but writing an implementation that can handle the wide variety of both compliant and slightly non-compliant traffic is an exercise in frustration.
This is not helped by the fact that people see the text protocol and think that it's easy to implement, so they go and write their own HTTP/1.1 server and leave it on the internet. Their server is probably not quite spec-compliant, so everyone else is left trying to interop with it.
Binary protocols are hard to debug by eye, but they aren't hard to write parsers for.
Implementing a text based protocol (SMTP, POP3, HTTP0.x/1.x) for a client application is certainly easier and less documentation is required. Knowing the clusterfk of the binary Office document formats, the newer text based ones re far easier to parse (be it XML or plain text doesn't matter). Be it binary or text based, one has to write a parser anyway. Only with text based protocol one could also use Regex or string match during, which is quite useful for non-production development/testing.
I read about "prioritisation" of data as a hint for the server, and less caching of data on the client. With the reoccurring "net neutrality" debates, let's hope this protocol cannot be misused/used to prioritise certain packets for parties who pay extra. I am not into this debates, but it would be certainly a disadvantage for startups over established parties. Given the many problems with SSL (heartbeat, broken/outdated certs, hijacked cert vendors) an HTTP/2 without SSL would be a nice fallback scenario - wildcard certs for new startups are still a bit expensive, especially if one will have to replace (=costs) the certs every few months due security concerns.
When you're parsing text, all kinds of crazy stuff can happen. You need to resize buffers as you read data, you need to know the escaping rules of each field, you need to know about line continuations, you have to know the text encoding, and many many other things.
Binary data in the abstract form has three elements: tag/type (may be inferred from position), data length (may be inferred from tag) and optional data itself. There are various ways to compose that information, but that's it otherwise. Binary protocols may be harder to read for people (you can just use wireshark dissectors though), but writing a correct and bug free de/encoder for one is massively simpler than for a text one.
By design, every text protocol will require more documentation than binary, because you need to include information about data escaping and encoding.
If you want to see this in practice, implement a client for something which does support both options. I recommend memcache.
Whether parsing binary is easier or harder than parsing text depends almost completely on the grammar of the language being parsed; and let's not forget, text is, of course, a type of binary format.
If I have to do ad-hoc parsing or generation, I prefer a text format, because I have lots of tools that understand text. If I need to do production-quality work, I prefer a binary format, because I need to be complete. But if I'm integrating multiple heterogeneous systems, I want a format that is trivial to inspect and test; that may mean a well-specified text format, like JSON or XML.
I'm fairly sanguine about HTTP/2 because it's at a lower level. If I were in the business of writing HTTP clients or servers on a regular basis (rather than using existing libraries), I'd be more concerned. I only do a telnet HTTP/1.0 session every 4 months or so.
But again, I have to disagree about parsing text ever being easier than binary. Basically for the same protocol, passing the same data and implemented in a sane way, the text protocol is the same as binary + variable length metadata + data escaping + value conversion + text encoding of metadata. I'm happy to challenge anyone with the following: it's not possible to create a simpler text protocol than a well designed binary protocol. (looking only at encoding/decoding, not debugging side)
Where by simpler I mean, less likely to get exploited, less ambiguous, shorter to document (when concatenating with docs of all encoding protocols you depend on, like JSON or XML)
Huh? That's irrelevant, surely? It doesn't speak to your assertion. The best binary formats don't necessarily need "parsing" at all; it could be a simple matter of mapping into memory and adjusting offsets, like an OS loader. I don't think there's any debate that binary formats can be designed so that they are far easier to load than text. We're not talking about the design of protocols here (in this subthread). We're talking about writing parsers.
Parsing an obscure binary format is harder than parsing a simple text format.
I'm not sure where do obscure binary formats come in. Http2 had a choice of slightly complicated binary, or more complicated text. Office had lots of programmers, even more money and simply didn't care. It's a completely different situation than http2.
So finally: why the obscure binary format? Http2's choice is good text or good binary really.
The Office "binary format" is simply the objects as they exist in-memory serialized to the disk. Doing it this way was a design decision made when machines were a lot more resource constrained, and fair enough, perhaps it could be revisited, but it was made for sensible reasons by people smarter than you.