Hello, everyone. I know this is probably the best place for this, but am I the only one that thinks Comet is pushing the limits of HTTP too far (no pun intended)? As far as I can read from the RFC, a client may create a long-lived connection, issue several requests, but the server MUST respond to these requests in the order they're sendt. I'm not trying to give the Comet crew (that's a cool name, btw) a bad name, but I get the feeling that doing this type of things in HTTP/1.1 is against the constraints imposed on the protocol. I'd absolutely love to get callback-type functionality in HTTP, but I'm just bothered by the nagging feeling that it should be done either as a different protocol or a new version of the HTTP protocol, since this type of protocol leverage gives a new set of challenges that should be seriously looked into. After all, a lot of the success of HTTP is in its ability to be simple, but extremely powerful.
Just some thoughts I had to get out somewhere... Regards, Kyrre --- Rob Heittman <[EMAIL PROTECTED]> wrote: > The thing I'm working on simply involves an > alternative to > handle(request,response) that allows the response to > be delivered to a > callback object, possibly and probably in another > thread. This is > principally valuable for AJAX style code and > critical path for the GWT > support I'm working on. To a certain degree, we > actually want a model here > that looks and feels very familiar to GWT users who > have worked with GWT-RPC > and would like to try a RESTful alternative. > > The idea of being able to "pin" a thread is probably > more applicable to the > issue of a long-lived request/response cycle (e.g. > Comet style), and > probably more valuable across the board, but less > critical path to what I'm > doing. > > Both of these asynchronous needs are under active > research and development, > and the implementation is probably interrelated > (synchronous processing can > probably be expressed in terms of a single callback > which can probably be > expressed in terms of chunked asynchronous > processing) ... the RFE gives > some code examples for how this might be true. > > Right now I am looking at the penalties and costs of > thread-safe Request and > Response objects across the board, a need which must > be sorted out before > any of the other async stuff can be safely > investigated. > > > On 2/6/08, António Mota <[EMAIL PROTECTED]> wrote: > > > > Hmm, let me try to understand, is there a effort > going on to include in > > Restlet some kind of "notification" to > asynchronous clients based on > > xmlhhttprequest callbacks and/or Comet-style > "push" techniques? > > > > > > > > > > On 06/02/2008, jbarciela jbarciela > <[EMAIL PROTECTED]> wrote: > > > > > > > Have a look at this RFE and its references: > > > > > http://restlet.tigris.org/issues/show_bug.cgi?id=143 > ... > > > > > > Ah, that's a wonderful wonderful compilation of > articles, so far I've > > > only read about Jetty's continuations, thanks > for the link > > > > > > > you guessed right > > > > > > I have my moments > > > > > > Cheers > > > Jaime > > > > > > > > > > > -- > > -- > > Melhores cumprimentos / Beir beannacht / Best > regards > > > > António Manuel dos Santos Mota > > > > mobile: +353(0)877718363 > > mail: [EMAIL PROTECTED] > > skype: amsmota > > msn: [EMAIL PROTECTED] > > linkedin: www.linkedin.com/in/amsmota > > > ------------------------------------------------------------ Kyrre Kristiansen ___________________________________________________________ Support the World Aids Awareness campaign this month with Yahoo! For Good http://uk.promotions.yahoo.com/forgood/
