[
https://issues.apache.org/jira/browse/WICKET-4879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13503278#comment-13503278
]
Zala Goupil commented on WICKET-4879:
-------------------------------------
Not really, because if you post on the event bus with two clients registered,
if I understand things correctly, the predicate which returns true sends the
response to both clients, even if the other one returns false.
Let me explain a little more what is the current behaviour. Let's say that two
clients A & B have the right @Subscribe method. Let's say that you send an
event e to the event bus for that method. Then A processes e and sends the same
response to both A & B. Then B processes the same event and sends a response to
both A & B, too. So we have two responses received by both A & B. I have an app
where it's visually obvious: I send a small notification in my @Subscribe
method. The notification displays two times in each browser A & B. Which is
what make me think it works like that. Plus, it looks consistent with what I
know from Atmosphere's Meteor API (which is called under the hood). Hence the
request for a Broadcaster-based solution.
If I use a predicate which returns true for A and false for B, here is what
apparently occurs: A sends its response to both A & B since the predicate
returns true. And B doesn't send anything since the predicate returns false.
But the * same * response returns to both A & B since it comes from A.
What I would like to be able to do is to have a response computed by B's
AtmosphereBehavior instance sent to B and a response computed by A's
AtmosphereBehavior instance sent to A. Because those 2 responses can
potentially be a little bit different from each other.
Does it make sense? Am I doing assumptions that I should not?
One more thing. Quoting wicket-atmosphere's JavaDoc: "The filter cannot rely on
any context. For example, the RequestCycle may not be available". This seems to
me a little bit limited. I fully understand why this is like this for the
predicate. But if we have a way to dispatch the right event to the right
@Subscribe method (or a channel implementation of any sort), maybe we will be
able to filter things with more context, so that would be potentially easier.
OK, any thoughts about that?
Kind regards,
Pierre
> Implementing channels in wicket-atmosphere
> ------------------------------------------
>
> Key: WICKET-4879
> URL: https://issues.apache.org/jira/browse/WICKET-4879
> Project: Wicket
> Issue Type: New Feature
> Components: wicket-atmosphere
> Affects Versions: 6.3.0
> Environment: Tomcat / Jetty
> Reporter: Zala Goupil
> Assignee: Emond Papegaaij
> Attachments: wicket-atmosphere-quickstart.zip
>
>
> Good evening,
> Now that both Tomcat & Jetty support native WebSockets, it would be a
> killer-feature to implement Comet / WebSockets channels. i.e. being able to
> have a channel id and to post a message to one client only or to all the
> clients who subscribed to a certain channel.
> For the moment, it is possible to do it, but to the (expensive) price of
> having a PerRequestBroadcastFilter and tweaking it if we manage to do it. But
> it would be great to have a link to the Broadcaster API from Atmosphere,
> which I think, supports this kind of things.That would probably be way more
> efficient than PerRequestBroadcastFilter tweaking.
> As of today, when posting a message to the event bus, all pages who have the
> @Subscribed-decorated method suitable to process this message will do it,
> which is not always desirable.
> I'm looking forward to hear from you.
> Regards
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
