Feature: Response callback fun about gun HOT 4 OPEN

I would like to see a better fledged interface proposal. Know which messages it is expected to replace, how it deals with data or trailers and so on.

I would favor changing reply_to to accept a {fun ..., St}. I don't know if that St should be allowed to change or not. Let's see if there's any benefits one way or the other. The St would be a way to give the Pid if you use a fun F/A form.

from gun.

If reply_to can be just a fun, then the fun can encapsulate a custom pid, like

reply_to => fun(Response) -> my_response_handler(MyPid, Response) end

I think it is almost equivalent to

reply_to => {fun my_response_handler/2, MyPid}

I don't mind the latter, but I don't think it is necessary. If St is allowed to change, then the fun use it to accumulate the response until IsFin is true, but I think it might be too complex. The user can do that in their own process instead, so we don't complicate the interface too much.

from gun.

Those funs don't survive module reloads. So we need to have a tuple at least as an option.

from gun.

Interesting. I didn't think about funs that become invalid when their module's old code is purged. Is it only a fun with explicit module like fun M:F/A that can survive a purge, i.e. not even fun F/A can survive?

Regarding the possibility to update St, we don't need it now but I think we can't add it later if we don't add in from the start.

So how about this proposal: reply_to => {Fun, St} where Fun is called as Fun(Response, St). If it returns {ok, NewSt} we keep NewSt, but otherwise (any other return value) the old St is kept.

To keep the inteface simple, it would receive exactly the same messages as the existing ReplyTo pid does.

from gun.