Why not just choose some very-low-maximum-growth header compression algorithm, combined with a default dictionary (containing the usual field names), and otherwise just keep HTTP. You could call it Header-Compression-Support: blah, and have the first request GET per connection of the server reply with something similar if it is supported, with further requests actually going the compressed route. Due to their repetitive nature the headers would likely compress very, very well as long as the compression dictionary is kept separate from that of the data being sent.

To deal with async issues, Header-Compression-Support could specify that it is supported while Header-Compression-Next could specify that from then on, that compression type would be used.

1) Client sends support header
2) Sender replies with normal packet and ‘header compression next’, meaning all its further sends will be using the specified form of compression
3) Client keeps sending normally (perhaps including the support header, but it’s redundant after the first, so maybe not) until it receives the server’s ‘header compression next’
4) Client then, knowing the server supports it, sends its own ‘header compression next’

So, being async, the server will have one request with its header classic HTTP, and the client will have two, or maybe three or four due to latency before it gets activated.

A big benefit of this over what I saw on your slides is that the field *values* will, over a couple requests eventually disappear from the data stream as well, as that information is repetitive too. It’s a not-too-complex solution that would massively reduce bandwidth use.

[…] most folks who use the term are talking about REST without the hypertext constraint. In other words, not RESTful at all. REST without the hypertext constraint is like pipe-and-filter without the pipes: completely useless because it no longer induces any interesting properties. The RESTful Web Services book doesn’t help the situation by renaming the hypertext engine as connectedness. That does nothing but obscure its role as the driving force in RESTful applications.

Care to elaborate a bit for us mortal undergrads? I do understand that the “hypertext restriction” is another name for “hypertext as the engine of application state”, but how exactly ROA or “RESTful Web Services” fail at it?

Roy Fielding: I won’t take credit for that idea, but I stand behind it.  Perhaps I talk to different people than Roy does, but many of the people I do talk to don’t, um, connect when they hear the phrase   Yet, when I poi…

One conversation on a thread? Which can always be referred to? I think people are becoming less and less clueful in regards to hijacking threads, and my experience with email archives is that even the best are hard to navigate and almost impossible to reliably link to specific messages over time. More importantly, the people who are participating in the discussion aren’t actively maintaining the links.

I have written thousands of email messages on web architecture, but if you search for them what you will find is the hundreds of comments on my email messages (not the messages themselves). I have no idea why. The digital world needs librarians too.

The primary difference seems to be the nature of archives and how they are linked. The pretty links of a blog (configured correctly) are referenced more consistently than the cross-references within email archives. As a result, the PageRank style of evaluating the quality of resources comes into play and I find it far easier to search for relevant blog entries than relevant email messages.

In any case, it is a rare day when I can have a coherent discussion with my peers on an email list (outside of the product-specific dev lists at Apache). This blog isn’t really for coherent discussion — it is for regurgitated conclusions. The discussion happens in the ripples.

….Roy

I was reading your first entry “I need to start organizing my own correspondence” after reading Stu’s and making a comment.

So i’ll ask the same thing of you as I’ve just asked Stu. Is there any reason you wouldn’t share a forum with your peers? I’m going nuts watching everyone broadcast from the comfort of their own blog, and never seeing the threads tangle, or conversations happen. Just your blog roll makes my eyes spin.

I understand the email deluge, which is everyone’s problem. But one conversation on a thread, above the radar, which can always be referred to, makes more sense to my universe than using email. And if everyone has a blog, which is the fashion now, we’re just substituting one deluge problem for another.

I love a puzzle to, but I won’t play the blog game because the deluge effect is so obviously coming, and I won’t try and finish a puzzle i know i can’t solve by myself.

If anything, the folks doing the most talking these days have talked themselves into the same corner where the AI systems failed — the closed-world assumption. These requirements are the antithesis of what Tim included in his Design Notes:

The Semantic Web is what we will get if we perform the same globalization process to Knowledge Representation that the Web initially did to Hypertext. We remove the centralized concepts of absolute truth, total knowledge, and total provability, and see what we can do with limited knowledge.