Jeanfrancois Arcand wrote:
> Hi Paul,
>
> Paul Sandoz wrote:
>> Salut Jean Francois,
>>
>> Thanks for committing Comet prototype stuff we worked on.
>
> Agree, it is nice to see the famous chat examples running on Jersey :-)
>
Indeed.
> I think we can
>> do a lot of nice stuff at the level of the application programming model.
>>
>> From what we did these might be the core Jersey runtime requirements:
>>
>> 1) The Grizzly response adapter when using comet should not close the
>> grizzly output stream.
>> Maybe it makes sense when Grizzly is configured for comet that it
>> ignores the close on a GrizzlyResponse.getOutputStream().close(), or
>> is that still required? If so Jersey needs to determine if Comet is
>> enabled or not.
>
> I think Jersey needs to know if Comet is enabled or not as some requests
> might needs to be committed (like a GET).
>
OK.
> For now we have focussed on Grizzly, but it should be easy to extend our
> work to use Jetty or Tomcat. So we should try to come with a generic
> approach.
>
It seems we need a way to set the state of the Jersey
HttpResponseContext e.g. CONTINUE (need better word?) or COMMIT (the
default). So on a Comet GET/POST it would set the state to CONTINUE then
the container would not close the output stream after writing the
status/headers/entity.
>
>>
>> 2) We need a way to easily re-write headers and entities on the
>> long-lived HTTP response context for pushing information.
>> Currently i think we hacked something together but we may be able to
>> expose a method:
>>
>> HttpResponseContext.push(Response r)
>>
>> that will write the status headers (if any) and entity (if any) and
>> has different semantics to HttpResponseContext.setResponse.
>> Such a method can throw UnsupportedOperation exception if not
>> implemented by certain containers or if called in non-push scenarios.
>
And is the state of HttpResponseContext is committed then it throws an
exception.
> +1
>
>
>>
>> 3) As i understand it the Comet GET method will pass the resource
>> instance to a created Comet handler and the Comet PUSH method will
>> get invoked later on that same instance.
>
> That's the recommended way. Comet is fairly new, but usually you use a
> GET to tell the container to suspend the connection and wait for server
> events (push). Now we might think about supporting POST as well, as some
> Comet application might use POSTs all over the place
>
OK.
Paul.
>
>>
>> For per-request resources the Comet GET will result in a new instance
>> of the resource class. We should ensure that the Comet PUSH does not
>> result in reentrant calls to Comet PUSH method as it will break the
>> life-cycle contract.
>>
>> For singleton resources all such methods can be reentrant. Thus we
>> could choose to enable reentrant push on such configured resource
>> classes.
>>
>> If we want to support reentrant PUSH on per-request life-cycle then
>> the Comet GET method needs to return the notifying object plus a
>> handler for managing the PUSH.
>
> I like the idea :-)
>
> A+
>
> --Jeanfrancois
>
>
>
>>
>> Paul.
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109