Re: Fwd: HTTP redirects make url-retrieve-synchronously asynchronous

[Richard M. Stallman]

    3. some backends (at least url-http, maybe others) sometimes decide not to
       call the callback, presumably as a way to signal an error (the operation
       can't be completed so the callback can't be called, basically).  This is
       a bug, but I don't know of anyone who's tried to tackle it yet.

What exactly is the bug?  It isn't clear to me.  Are you saying that
they should also call the callback function to report failure?

That seems like a good idea on general principles.  I don't know how
much of a change it would be.  Is the calling convention easy to
extend for this?

    2. sometimes the callback gets called in another buffer than the one
       returned by url-retrieve.

One solution would be to give the first buffer a local variable that
would, in this case, point to the second buffer.  Then
url-retrieve-synchronously could check the local variable, which would
tell it to check the process in the other buffer.

That solution would be safe, since it would not involve changing
general calling conventions.

    They (and url-retrieve) should either take an optional destination buffer as
    parameter or they should simply not return any buffer at all and the
    destination buffer should only be made known when the callback is called.

I don't much like the idea of that big a change in calling conventions.