Re: [Resin-interest] Resin, Comet applets - anyone?
On Dec 14, 2007 5:34 PM, John C. Turnbull [EMAIL PROTECTED] wrote: Has anyone tried using a combination of Resin, Comet and applets? I see examples using Comet with HTML-based technologies but is this also possible for plain old applets? I can't figure out how it would work (or IF it would work). ive done only crude work with applets; many years ago at that. however, if applets have a way to send an http request to the server it is conceivable that the 'comet effect' could be recreated with them. basically, all comet does is keep the http connection open. its expensive, but as you know offers the ability to 'push' to the client. -nathan ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin, Comet applets - anyone?
On Dec 15, 2007 12:34 AM, John C. Turnbull [EMAIL PROTECTED] wrote: What I don't understand is how the servlet maintains the connection to the applet and exactly how the methods in the applet are invoked from the servlet. im not very sure how this works either. if i were to guess; id say in its simplest form, rather than sending data back to the browser and terminating execution; data is sent periodically in the body of a loop. In the examples of Comet given, the messages sent back to the client are through HTML posts which contain JavaScript. there are a few different techniques that differ based upon the content of the data returned by the server. script centric; this contains javascript data centric; xml or json content centric; xhtml so you can favor one or mix and match to suit your needs. the prototype library (and ruby on rails [not that i use it ;)] tend to favor a content centric approach. Would it work the same way for applet? I mean is it a case that the servlet sends back HTML with embedded JavaScript calls which then invoke methods on the applet or is there a more direct way to invoke the applet methods directly? i imagine this would be very similar, in general. rather than invoking applet methods directly though, i imagine they would be invoked indirectly. the best thing i can conjure up is a client-side controller. so lets say the server sends data over to the client; the data can represent whatever, like say class names, object instance names, actual parameters, and so forth. given this data the client side controller could dispatch them. well suited for the command pattern, i believe, (dont quote me on that [ive yet to implement command pattern..]) -nathan ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin Comet
I've updated the Comet API to make it more like the Servlet API and
to avoid dependencies on Resin details. Details are at
http://caucho.com/resin-javadoc/com/caucho/servlet/comet/package-
summary.html
The example has been updated at
http://caucho.com/resin-3.1/examples/servlet-comet/
The main changes are
1. the package (com.caucho.servlet.comet to match javax.servlet),
2. CometController is now an interface
3. CometServlet is now an interface
4. GenericCometServlet replaces the older class
5. Added CometFilter and CometFilterChain
You might also want to look at the new streaming capabilities of
Hessian as an example protocol for use with comet: http://caucho.com/
resin-javadoc/com/caucho/hessian/io/Hessian2StreamingOutput.html
The Comet API now looks like:
public interface CometController {
boolean wake();
Object getAttribute(String name);
void setAttribute(String name, Object value);
void close();
}
public interface CometServlet extends Servlet {
boolean service(ServletRequest requet, ServletResponse response,
CometController controller);
boolean resume(ServletRequest request, ServletResponse response,
CometController controller);
}
public interface CometFilter extends Filter {
boolean doResume(ServletRequest request, ServletResponse response,
CometFilterChain next);
}
public interface CometFilterChain extends FilterChain {
boolean doResume(ServletRequest request, ServletResponse response);
}
-- Scott
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin Comet
What exactly is Comet? what problem does it solve? When would I use it? Alan Scott Ferguson wrote: I've updated the Comet API to make it more like the Servlet API and to avoid dependencies on Resin details. Details are at -- Alan Wright Athene Systems tel 0845 230 9803 Athene Systems Limited Registered Office: Shieling House Invincible Road Farnborough GU14 7QU Registered in England and Wales No. 3156080 ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin Comet
On Oct 4, 2007, at 8:20 AM, Alan Wright wrote: What exactly is Comet? what problem does it solve? When would I use it? Comet is for streaming responses from the server, as a replacement for polling. (Comet doesn't stand for anything, unfortunately. It's just a unique identifier.) The server sends a new packet of data to the client when an event occurs. The best example might be a Flash administration or monitoring application that updates the client dynamically as events arrive from the server. The demo examples tend to be simpler, e.g. a chat application, which have the same basic properties as a real application, i.e. asynchronous updates, but might not be directly useful. It's a somewhat specialized capability, but if the application needs async notification of the client, it's very useful for the app server to provide the infrastructure. Resin's Comet is solving two problems 1) Async notification/communication of the servlet thread using the CometController. This is the main issue, really. The servlet thread/ request is single-threaded/synchronous, but Comet applications are intrinsically multithreaded/async. Resin's implementation deals with most of the threading issues, which will let applications avoid threading issues later on. 2) Thread detachment and reattachment from the idle servlet request. While the Comet servlet is idle, waiting for the next event, Resin can detach the thread and use it for another request. This is a nice side-effect and many comet implementations push #2, but really it's #1 that's the main issue. -- Scott Alan Scott Ferguson wrote: I've updated the Comet API to make it more like the Servlet API and to avoid dependencies on Resin details. Details are at -- Alan Wright Athene Systems tel 0845 230 9803 Athene Systems Limited Registered Office: Shieling House Invincible Road Farnborough GU14 7QU Registered in England and Wales No. 3156080 ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin Comet
Hi Scott, I would have a few questions regarding this implementation: 1. Are Filters applied before the service/resume calls are invoked? If they are applied to both, then is it possible to specify if a filter is to be applied only to resume() or only to service()? 2. What is the state of the request scope (attributes and parameters) at the start of the resume() call? - Are the request parameters obtainable in resume(), too, or only in service()? - What is the state of the request attributes present at the start of the resume() call? a. The same as at the end of the preceeding resume/service method? b. Empty? c. The same as at the end of the service method? d. The same as at the start of the service method? e. Undetermined? 3. Is the resume() call carried out on the same thread as the wake() call triggering it, or is it carried out on a separate thread? Thanks in advance and best regards, Robert Varga On Thu, 20 Sep 2007 11:24:42 -0700, Scott Ferguson wrote: The 3.1.3 snapshot includes a new implementation of Comet for Resin servlets. There's a sketch of an example at http://caucho.com/resin-3.1/examples/servlet-comet/index.xtp Javadocs are at http://caucho.com/resin-javadoc/com/caucho/servlets/comet/ package-summary.html The basic model is similar to the normal servlet, except there's a new service() and a resume() call in the AbstractCometServlet. The CometController is the main object that's passed from the servlet to your application comet code. Its main methods are wake(), close (), and setAttribute()/getAttribute(). The CometController is thread-safe. As always, the ServletRequest and ServletResponse and the PrintWriter/ServletOutputStream are *not* thread-safe. You must not store the request/response or output in object or pass them to other threads. The only way other threads in your application can talk to the Comet request is through the CometController. Data is passed through get/setAttribute (which sets request.setAttribute in a thread-safe manner) and the servlet is resumed with wake(). We'll cleanup the example in a bit to make a bit more sense. The 3.1.3 release has been delayed another week (due primarily to Quercus issues), so we're now aiming for the week of October 5. -- Scott In order to protect our email recipients, Betfair Group use SkyScan from MessageLabs to scan all Incoming and Outgoing mail for viruses. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Resin Comet
The 3.1.3 snapshot includes a new implementation of Comet for Resin servlets. There's a sketch of an example at http://caucho.com/resin-3.1/examples/servlet-comet/index.xtp Javadocs are at http://caucho.com/resin-javadoc/com/caucho/servlets/comet/package- summary.html The basic model is similar to the normal servlet, except there's a new service() and a resume() call in the AbstractCometServlet. The CometController is the main object that's passed from the servlet to your application comet code. Its main methods are wake(), close (), and setAttribute()/getAttribute(). The CometController is thread-safe. As always, the ServletRequest and ServletResponse and the PrintWriter/ServletOutputStream are *not* thread-safe. You must not store the request/response or output in object or pass them to other threads. The only way other threads in your application can talk to the Comet request is through the CometController. Data is passed through get/setAttribute (which sets request.setAttribute in a thread-safe manner) and the servlet is resumed with wake(). We'll cleanup the example in a bit to make a bit more sense. The 3.1.3 release has been delayed another week (due primarily to Quercus issues), so we're now aiming for the week of October 5. -- Scott ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
