On 4 Dec 2013, at 11:45, Pavel Bucek <pavel.bucek_at_oracle.com> wrote:
> Hi Gerard,
>
> sure, makes sense. (Although we could not use JDK 8 features yet... ehm) :-)
Well sure; but if you design the feature with a single method interface then it will work nicely with Lambdas in the future. :-)
>
> Feel free to file new RFE agains Tyrus. The other option might be doing some tiny internal cache and then user should be able to have similar advantage with possibility to use lambda expressions on result of Session.getOpenSessions().. maybe I like this a little bit more than adding broadcast method.
I did think about this; but it would make it much harder to perform the same filter across a Cluster as per TYRUS-278
>
> Anyway, even this might be resolved as part of solution of RFE you are going to file, so please do it.
Okay I will put something together this afternoon, once I have figured if and how Lamda serialise.
>
> Thanks!
> Pavel
>
> ps.: did you have any interesting questions or feedback related to WebSocket/Tyrus?
The main question I got was just how many connections Tyrus would support on WLS, I fudged and suggested thousands in theory. Would would be the official line? Isn’t the maximum limit for on IPv4 address something like (65535-1024 / 2) as you need two ports for each websocket?
Gerard
>
> On 04/12/13 11:40, Gerard Davison wrote:
>> So I was doing a presentation on WebSockets yesterday and it occurred to me that the “broadcast” method should really be extended so allow some kind of filtering on which connections the events is sent to, for example
>>
>> peer.broadcast(s -> s.getUserProperties().contains(“NAME”)).message(message);
>> or
>> peer.broadcast(message, s -> s.getUserProperties().contains(“NAME”));
>>
>> Does this seem reasonable for a range of use cases, if so I will raise a ER.
>>
>> Gerard
>>
>>
>>
>