Hi Viktor,
hm, the idea sounds interesting. A bit like a specialized gen_statem, at first
thought.
But I guess I won't be easy to find something that is special enough to warrant
not using a gen_statem itself, but general enough to be able to cover most of
the common use cases with it.
Depending on the characteristics of the external service, the requirements for
the client, and the behavior of connection between the two, many possibilities
exist which the hypothetical gen_client should be able to account for.
Let's hear what Fred thinks ;)
> A different note regarding automatic reconnects in clients: They may be
> problematic, since there may be some state associated with the
> connection (such as an ongoing database transaction) which is lost if
> automatic reconnect is done without care. Crashing instead of
> reconnecting makes this handling way simpler (or at least it moves the
> problem to somewhere else). How would you best solve this using the
> hypothetical gen_client behaviour?
Automatic reconnecting is not a problem in itself if you ask me. It is a
problem if it happens _transparently_, ie if processes using the client have no
way of noticing it. I think it should even be made _impossible_ to use a
reconnected client without the user process being informed and performing some
extra steps in order to use it again.
What I'm imagining (without having given it too much thought) is to let the
client manage a token (a reference maybe) which users can ask for and have to
provide together with requests. On reconnect, the client changes that token,
thus invalidating all requests made with the old one. Like this:
* client C is connected, his current token is T1
* user U wants to use C and asks it for its token, receives T1
* U sends {T1, Request1} to C; C accepts as T1 matches its own token
* C's connection fails, he changes the token to T2 and reconnects
* U, unaware of C having reconnected, sends {T1, Request2} to C; C rejects
because T1 does not match its own token
* thus, U knows that C has reconnected and that any connection-related state is
lost; if he decides to continue using C, he must ask for the current token, and
receives T2
* U sends {T2, Request2} to C; C accepts as T2 matches its own token
* etc
Kind regards,
Maria
_______________________________________________
eeps mailing list
[email protected]
http://erlang.org/mailman/listinfo/eeps
