-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feedback #1
Comments
Having to call |
One immediate problem is that this will not work for modules that still want to handle some calls, for example |
It was assumed that
The set of actions you can use there is limited:
Oh, but you can handle calls and other external events by giving a callback (a fun or |
@lhoguin we're currently exploring another approach btw, a behavior which we dubbed It takes care of the timing and retrying, and implementing modules only supply the logic for attempting to get the resource you want. This can in fact even be a multi-step process (like, establish a connection, do some protocol handshake, try a upgrade to SSL, do another handshake, etc). In the end, it just hands the resource over to the client process (or gives up), and that's it then (with sockets, there is also another step of giving it away to the client process, but that should be doable). At a glance, this offers more flexibility, which is important if this is supposed to make its way into OTP, and has another benefit in that you can employ several agents at once if the client needs several resources to become operational. Last but not least, it can be used from any kind of client process, not only It's more complex to use, probably, though... @juhlig is currently drafting it up and experimenting, I'll let you know when there is something to see ;) |
I have no idea how to use it. A demo would be good. |
I admit the README docu is a bit sparse 😅 I'll slap together an example on monday. Too tired right now... 😞 |
@lhoguin an example is up, not much, but it's something you can play with. For comments on |
OK. It is too simplistic. Gun has a few different |
@lhoguin are you referring to |
I am referring to |
I'm not trying to argue for one or against the other, don't get me wrong, but I really think This is the difference between the two approaches, ie what each one is:
Actually, from my point of view anyway,
At the same time, Finally, if you need several steps to make a resource operational (like DNS -> TCP -> SSL -> ...), you can wrap them in one run, but I think it would be the better to handle that by means of your
With both mechanisms, if you need to backtrack (eg With that all said, both implementations are far from perfect yet. Right now we are thinking of adding "phases" or "stages" to |
OK I probably misunderstand how to use The I know it doesn't work with things other than Perhaps |
Again, not arguing, just trying to clear things up some more ;) You seem to have your heart set on
Yes, read more below.
An Erlanger shying away from yet another process, that's just short of an atheist pope 😁 What has the world come to, I wonder 😅 j/k, but seriously, what's the problem here?
Yeah ^^; At some point, it may not be worth the hassle and you could just use
... which you can't do from a state enter call, as it involves a state change. That complicates matters I think.
Hm, something similar can be done with The difference is that it won't turn your virgin gun connection into an operational gun connection, it delivers the things you need so that a virgin gun connection can turn itself into an operational one.
And here it starts getting complicated... You can't return just anything you could from a state callback, at a quick glance the same restrictions as for what a state enter call could return would apply. That means checking the return values, and adapting the checks in case
You think so? I would say it solves the same problem (in a nutshell: try (and retry) to get a resource), only with a different approach, and different requirements for how to use them. |
(I probably know too little about |
When you have 1 million connections, and you make those connections use two processes instead of one, you end up with a substantial amount of wasted memory. I think The state enter call is not important. You can easily switch to a state and trigger an internal event and do the switch there. You do not have to do it in the state enter call. Gun uses the switch state and trigger event multiple times when setting up the connection already.
I think that's the difference in the problem being solved.
The So the problem they solve, while similar, is not the same. I cannot just use It's OK to not allow everything to be returned. I just need to do replies, perhaps timeouts and such. I don't think you need to adapt to new PS: Haet |
Ok, was just interested ;)
Ok, I refactored it. Everything non-
One of those famous typos I guess? =^^= |
I will have to try if that's enough to use it with Gun before making further comments I think. |
Oh, by all means, give it your worst 😉 Anyway, new ideas coming in (in part courtesy of @juhlig, thanks).
I'll explore tomorrow 😃 |
Not sure I understand, but you can't know which events must be postponed and which events must be handled by the user's |
Everything that is not a However, don't know what you think, but if I look at it now, the whole thing has turned into just a very complicated, cumbersome, restriction-laden way to use a timer :P |
I think I misunderstood parts of Configuration can be like:
I do not think there is much more to be done:
I know this feels backward with regard to push/pop and how
This value is likely to be already defined by the user if they want a hard limit on the number of retries (Gun defaults to 5). Another value that is likely to be useful is the user module's own state, so maybe have a Forget about the resource fetching, and focus on just waiting. This is the missing functionality that we reimplement just about everywhere. If I could switch to a |
Ok, so in a nutshell, you want something that waits for the sake of waiting, not for something to happen, right? :) |
Whether something happens afterwards is of no concern to |
I see... hm, ok then, but in that case I don't see much value in it, I have to admit. Or maybe I'm getting things wrong again, so let's clear things up more before I start on a wild goose chase again ;) What you would do now is roughly this:
With
With all this, it looks to me that there is not much room for making things simpler here, that the things you could simplify are special cases (like ignoring/postponing), and that on the other hand you have to do other things in a more complicated way (entering The only useful thing seems to be the waiting time calculation, and there is only one really useful function for that, |
Ok, that could actually be done by re-inserting the state timeout via |
... in which case you need a function clause for that in the users statem, too. If you set up |
I think it's about as useful as the I suppose there could be a way to also manage the number of retries as well, if the I don't know if you need the extra event when switching to In that case |
Opening this to provide feedback. But it might take a few days to get it all out.
I think in general that it is good. Right now I am mostly wondering about whether it is a good idea to validate the options every time we enter "wait" mode. Though I suppose it's not very heavy anyway.
The text was updated successfully, but these errors were encountered: