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

[Stefan Monnier]

>     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?

Yes.

> 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?

Not directly.  The most natural way to do that is to pass the
success/failure information as a parameter to the callback function, but if
we don't want to break existing code, we could pass the info via a local
variable in the destination buffer.

>     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.

Yes, sounds like a good quick-fix.

>     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.

Neither do I, especially not that close to a release.  OTOH we haven't
released URL yet so it's the last opportunity to clean up the API.


        Stefan