W3C home > Mailing lists > Public > uri@w3.org > October 2007

Re: URI Templates - optional variables?

From: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Wed, 17 Oct 2007 09:43:54 +0200
Message-Id: <41037C9E-4937-4E5C-A9DA-D437A51E8851@greenbytes.de>
Cc: Mark Nottingham <mnot@mnot.net>, URI <uri@w3.org>
To: Roy T. Fielding <fielding@gbiv.com>


Am 16.10.2007 um 23:58 schrieb Roy T. Fielding:

>
> On Oct 16, 2007, at 2:11 PM, Mark Nottingham wrote:
>> On 17/10/2007, at 3:06 AM, Roy T. Fielding wrote:
>>
>>>> Ceterum censeo: in my view the templates would benefit from an  
>>>> easier readable syntax.
>>>
>>> Easy to read by whom?  I went through the readable bits with HTTP
>>> and it turned out to be a big mistake.  Nobody reads HTTP in real
>>> practice, yet the overhead of parsing HTTP messages is huge.
>>
>> I do, and my developers do; it greatly helps them understand and  
>> debug the protocol.
>
> You don't pull out your trusty text editor and watch the
> stream go by -- you filter it through a protocol analyzer that maps
> the packets to a stream of text.  The same analyzer can map the
> application level as well.  The benefits of an ASCII protocol are
> a total myth aside from the framing issue: it allows most transport
> errors to occur unnoticed, and hence seems like it works better than
> a protocol that would report the error.

Well, in my experience, I enjoy great benefits from the ASCII, human  
readable HTTP. And most of it is in development, but very much in  
customer trouble shooting scenarios. Agreed, protocol analyzers could  
be brought in (easier on your development machine than on customer  
installations), but it just saves so much hassle and time (and so  
money) when you can read it raw.

The problem with protocol analyzers is that they would need to  
conform to a common text output format to enable easy development of  
further analyzer tools. And then you need to define a normative way  
for transforming the binary protocol, without losing semantics, into  
an ascii representation.

This all can be done, but, well, it works amazingly well without it.

> Yes, I still use telnet to test web servers, but that is not real
> practice.  I could just as easily test with a perl filter.  Let's
> focus on real protocol benefits, not imaginary ones.

Well, when I am on a Windows Server Customer Installation, I really  
like telnet.

//Stefan
--
<green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany
Amtsgericht Münster: HRB5782
Received on Wednesday, 17 October 2007 07:44:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 13 January 2011 12:15:37 GMT