Re: more url-utils?

[Ted Zlatanov]

On Mon, 16 May 2011 21:52:43 +0200 Julien Danjou <address@hidden> wrote: 

JD> On Mon, May 16 2011, Ted Zlatanov wrote:
>> I'm trying to avoid that approach: we just established the headers are
>> almost never necessary in the buffer.  So we should not ask the API
>> users to do anything extra to remove them.

JD> That can be true. When you fetch an URL, you want to know if the fetch
JD> result is a 200 OK or a 404 Not Found. That's the absolute minimum thing
JD> you want to do if you plan to write correct code.
JD> So just dropping the header sounds like a very bad programming practice,
JD> and not something I'd encourage.

You won't get a HTTP status (or any headers, sometimes) from a non-HTTP
URL.  So the status is only useful in some cases and relying on it makes
the code inflexible, depending on the transport protocol's artifacts.

JD> I wrote code with url.el. And what I always did is (search-forward
JD> "\n\n") to move point between headers and content, and then parse the
JD> headers to at least check the return code (expecting 200 usually).

That's a symptom of a bad API that tied you to HTTP headers and what I
was trying to eliminate.

On Mon, 16 May 2011 16:53:37 -0300 Stefan Monnier <address@hidden> wrote: 

>>>> After looking at many examples in Emacs, I can't find or think of any
>>>> need for the headers *as text* in the code I've seen.  I would:
SM> That sounds right.
>> ...so can I go ahead with my proposal or would you rather be
>> conservative and keep the old behavior, making API users turn off
>> headers explicitly?

SM> There are 3 parts.
SM> - removal of header text.
SM> - backward compatibility.
SM> - providing header info in a non-textual format.

Ah, OK.  So my proposal does not fit because you want backwards
compatibility.  I was hoping to eliminate the bad API altogether but
this is at least a step forward.  Let me know if you want me to
implement any parts of this.

Thanks
Ted