Salut Jean Francois,
Thanks for committing Comet prototype stuff we worked on. 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.
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.
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.
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.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109