Skip to content
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

Support association of connection with connection handler actor #62

Open
ghost opened this issue Nov 21, 2014 · 1 comment
Open

Support association of connection with connection handler actor #62

ghost opened this issue Nov 21, 2014 · 1 comment

Comments

@ghost
Copy link

ghost commented Nov 21, 2014

It would be great if there were a means to name the connection handler actor based on some information available in the upgrade request. I'm thinking, for example, of a custom header that provides an ID, and that ID (presumably URL encoded) can be used as the name of the connection handler actor. The problem, of course, is that the connection handler actor already exists, and I don't think there's a way to name the actor after the fact. So presumably the implementation would create a new connection handler with the right name, register it as the handler, and stop the existing connection handler.

The goal is for clients to be able to identify themselves, and for the application to be able to use Akka routers, ActorSelections, etc. to communicate with specific clients (I'm assuming that's what the send() methods are for).

Does this make any sense? Is there a straightforward way to do it?

@Alain-Bearez
Copy link

Paul,

Using the WebSocket in order to maintain bidirectional communication between the client and the server can be acheived with no "identification" of the client end.

What you might actually want is to have a specific handler actor responsible for a particular URL such as I tried to exemplify in my template at:
https://github.com/cuali/SprayEasterEggs/blob/wandoulabs/src/main/scala/reactive/api/ReactiveApi.scala#L29-L34

In this way, the connection handler remains anonymous while you have a clear route to some explicitly named actor that will handle the effective communication messages.

Would this resolve your concern?

Regards,
Alain

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant