Skip to main content

[jsr362-observers:] [jsr362-experts:] Re: Re: Asynchronous processing support

  • From: Julien Viet < >
  • To:
  • Subject: [jsr362-observers:] [jsr362-experts:] Re: Re: Asynchronous processing support
  • Date: Wed, 30 Oct 2013 08:53:14 +0100
  • List-id: <jsr362-experts.portletspec3.java.net>

a few related questions on top of my mind:

- how the client get the websocket address to connect to that will reach the 
portlet container (related to next question) ?
- server side API ?
- client side API ?
- both ?

- is the portal playing a mediation role here or not ? (I guess yes)
1/ yes : more complex to get the address since it involves the portal
2/ no : simpler since the portlet container could use the native websocket of 
the target env

- performance : how about multiplexing websocket if the portal plays 
mediation role ?

On 28 Oct 2013, at 16:52, Martin Scott Nicklous 
< >
 wrote:

> Support for websocket is on the list of new stuff for JSR 362, so I think
> we should address websocket support in any case.
> 
> The question is whether we need to specify it as part of the Ajax support.
> I just put up a new Ajax proposal in which the JavaScript module for
> portlet support on the client is considered to be part of the
> vendor-specific implementation. If we go that route, we would only need to
> specify the JavaScript API for use by portlets, but would not need to
> describe the transport mechanism between the client and the server. We
> would specify neither the messages nor the transport protocol, so we would
> not need to mention websocket as part of the Ajax discussion.
> 
> But we would need to address it separately.
> 
> regards,
> Scott
> 
> 
> 
> Julien Viet 
> < >
>  wrote on 23.10.2013 13:00:00:
> 
>> From: Julien Viet 
>> < >
>> To: 
>,
>> Date: 23.10.13 13:00
>> Subject: [jsr362-observers:] [jsr362-experts:] Re: Asynchronous
>> processing support
>
>> it is also in the air according to last week discussion.
>
>> my opinion is that websocket covers other use cases that important too.
>
>> On Oct 23, 2013, at 12:15 PM, Werner Keil 
>> < >
>>  wrote:
>
>> Julien/all,
>
>> I know it's often a buzzword, but given it is a HTML5/W3C standard
>> allowing other languages than just Java to communicate, how about
> WebSockets?
>
>> Cheers,
>
>> Werner Keil | JCP Executive Committee Member | Eclipse UOMo Lead,
>> Babel Language Champion | Java Godfather
>> Twitter @wernerkeil | @JSR354 | #EclipseUOMo | #Java_Social | #DevOps
>> Skype werner.keil | Google+ gplus.to/wernerkeil
>
>> * Nighthacking with Stepen Chin Fall 2013: Nov 2013, Germany. Werner
>> Keil, Eclipse UOMo Lead will hack "M2M", "UOMo" and other cool Java
>> Embedded stuff
>
>> * JMaghreb 2.0: Nov 7-8 2013, Casablanca, Morocco. Werner Keil, JCP
>> EC Member, JSR 354 EG Member may present "Java Social", "JSR 354"
>
>> * Eclipse DemoCamps Fall 2013: Nov/Dec 2013, Germany, Austria,
>> France. Werner Keil, Eclipse UOMo Lead, Babel Language Champion will
>> present "M2M", "ETCS", "Triple'E class DevOps"
>
> 
>> On Wed, Oct 23, 2013 at 11:30 AM, Julien Viet 
>> < >
> wrote:
>> Hi Scott,
>
>> I would welcome asynchronous processing support in Portlet 3.0
>> (including JSR 286 API) pretty much like it exists since Servlet 3.0
>
>> This would align portlet 3.0 with servlet 3.0 and improve the
>> portlet programming model for use cases that are not covered today.
>
>> Is it something we are planning to work on soon ? can you tell us in
>> which position it is on the roadmap.
>
>> cheers
>
>> Julien
> 



[jsr362-observers:] [jsr362-experts:] Asynchronous processing support

Julien Viet 10/23/2013

[jsr362-observers:] [jsr362-experts:] Re: Asynchronous processing support

Werner Keil 10/23/2013

[jsr362-observers:] [jsr362-experts:] Re: Asynchronous processing support

Julien Viet 10/23/2013

[jsr362-observers:] [jsr362-experts:] Re: Re: Asynchronous processing support

Martin Scott Nicklous 10/28/2013

[jsr362-observers:] [jsr362-experts:] Re: Re: Asynchronous processing support

Julien Viet 10/30/2013

[jsr362-observers:] [jsr362-experts:] Re: Asynchronous processing support

Martin Scott Nicklous 10/28/2013
 
 
Close
loading
Please Confirm
Close