- From: Michael Enright <michael.enright@gmail.com>
- Date: Thu, 2 Nov 2006 10:05:56 -0800
Although the XMLHttpRequest has the capability of making a DOM available from the resulting text, the client and server don't have to make use of it. One could take the responseText and pass it to eval() if the other end sent JSON. A BEEP API should support any valid use of BEEP, just as XMLHttpRequest actually supports any valid use of HTTP, not just XML transfers. On 11/2/06, Ted Goddard <ted.goddard at icesoft.com> wrote: > > On 2-Nov-06, at 5:05 AM, Dave Raggett wrote: > > > well how about an XMLBEEPRequest specification then? > > > > Beep is kind of like a bidirectional version of HTTP and includes > > multiplexing capabilities with stream prioritization, see: > > > > http://beepcore.org/index.html > > > > Beep isn't in widespread use as yet, but is well thought off > > by the IETF folks. > > This would require the standardization of a JavaScript API for > BEEP, but it would be worthwhile because BEEP is explicitly > designed for building new protocols. BEEP messaging would > probably map better into JavaScript than a pure socket API. > (Would we want to insist that the payload be XML?) > > Of course, it wouldn't work if it was only implemented in the > ICEbrowser ... (so I'm curious what other browser developers > think of the idea) > > Regards, > Ted. > > > Dave Raggett <dsr at w3.org> http://www.w3.org/People/Raggett > > > > >
Received on Thursday, 2 November 2006 10:05:56 UTC