Jonas Sicking wrote:
...
Similarly content negotiation is something I would say is even more
doubtful that it has provided any value. The only site where I can
remember seeing content negotiation actually used is on w3.org, an
organization that is safe can be considered experts on web standards.
On Sat, Aug 15, 2009 at 2:59 AM, Julian Reschkejulian.resc...@gmx.de wrote:
However even here things immediately failed. When firefox started
claiming that we supported application/xml, several urls stopped
working since the browser was sent the XML file used to generate the
specification,
On Tue, Aug 11, 2009 at 7:46 PM, Greg Wilkinsgr...@mortbay.com wrote:
Jonas Sicking wrote:
Can you suggest changes to the WS protocol that would make it a better
general-purpose protocol?
There were several threads on the IETF HYBI mailing list with some such
proposals:
Jonas Sicking wrote:
I agree we should use the experiences from HTTP. However it seems like
we have different experiences.
For example mime-types in HTTP have a very troubled record. Look at
Adam Barth's draft [1] for what browsers are forced to do to stay
compatible with the web.
On Wed, Aug 12, 2009 at 1:10 AM, Greg Wilkinsgr...@mortbay.com wrote:
Jonas Sicking wrote:
I agree we should use the experiences from HTTP. However it seems like
we have different experiences.
For example mime-types in HTTP have a very troubled record. Look at
Adam Barth's draft [1] for
Jonas Sicking wrote:
The only site where I can
remember seeing content negotiation actually used is on w3.org
fwiw, MXR (and even LXR) uses some content negotiation, and it
generally magically works. OTOH it's transparent, so you shouldn't
see it :).
But yes, I'd say that content negotiation
Missed a few parts to reply to:
On Wed, Aug 12, 2009 at 1:10 AM, Greg Wilkinsgr...@mortbay.com wrote:
Of course the 0x80 length framed binary data type could be
used to send mime encoded messages, but then there would need
to be other standards to work out what style of meta-data was
used -
Jonas Sicking wrote:
I'd rather not debate about which process should be used to get to a
good protocol. I'd rather debate concrete proposals.
Sure.
So I think I'll keep this response short and see if I can
come up with a BWTP mkII proposal that addresses
the feedback that I've received.
Wellington Fernando de Macedo wrote:
message segmentation (...) aren't much important in
bidirectional-communication.
No. I'm wrong. Because of virtual connections message segmentation is
necessary.
I think WS could support these features (like they are specified in the
BTWP proposal)
On Tue, Aug 11, 2009 at 2:45 PM, Wellington Fernando de
Macedowfernandom2...@gmail.com wrote:
Hi, I've looked at the BWTP proposal. My feedback is here :)
One thing that I was curious to get your input on is: Does the fact
that BWTP syntax looks a lot like HTTP make implementing a BWTP client
in
On Tue, Aug 11, 2009 at 4:50 PM, Greg Wilkinsgr...@mortbay.com wrote:
Wellington Fernando de Macedo wrote:
message segmentation (...) aren't much important in
bidirectional-communication.
No. I'm wrong. Because of virtual connections message segmentation is
necessary.
I think WS could
Jonas,
Jonas Sicking wrote:
Can you suggest changes to the WS protocol that would make it a better
general-purpose protocol?
There were several threads on the IETF HYBI mailing list with some such
proposals:
http://www.ietf.org/mail-archive/web/hybi/current/maillist.html
An example of
Hi Greg,
On Aug 7, 2009, at 10:07 PM, Greg Wilkins wrote:
Again this is valuable feedback.
That's three -0' or -1's on the look-a-like-HTTP approach.
I'll ponder what sort of simplifications could be made
if the HTTP style is dropped.
I'm not sure the HTTP-style framing is necessarily a
On Fri, Aug 7, 2009 at 10:07 PM, Greg Wilkinsgr...@mortbay.com wrote:
Jonas,
taking some of your comments out of order
My gut feeling on BWTP vs. websocket is that BWTP carries some
unneccesary complexity/overhead by allowing arbitrary headers in each
frame, whereas websocket is
On Fri, Aug 7, 2009 at 11:20 PM, Maciej Stachowiakm...@apple.com wrote:
Hi Greg,
On Aug 7, 2009, at 10:07 PM, Greg Wilkins wrote:
Again this is valuable feedback.
That's three -0' or -1's on the look-a-like-HTTP approach.
I'll ponder what sort of simplifications could be made
if the
Jonas Sicking wrote:
On Fri, Aug 7, 2009 at 10:07 PM, Greg Wilkinsgr...@mortbay.com wrote:
Out of curiosity, what advantages do you see with having a declared
content-type? I can think of a few, but wanted to know which ones you
had in mind.
There are several reasons and use-cases.
Firstly,
Thanks for the heads-up. This comes at an auspicious time, because
we're now starting on WebSocket implementation in WebKit, and the
implementation seems likely to someday ship in Safari, Chrome and
other WebKit-based browsers.
For what it's worth, we are not absolutely wedded to the
Maciej Stachowiak wrote:
This proposal looks a bit more complicated than the WS protocol, so it
may take a bit to digest.
Maciej,
BWTP is indeed more complex that the base websocket protocol
I think this is one of the key differences between the approach taken
for the websocket protocol,
On Aug 7, 2009, at 12:25 AM, Greg Wilkins wrote:
But if your starting point is a working HTTP client or server, then
the work needed to implement BWTP should not be too significant,
as the additional complexities (Header fields and mime encoded
content) are handle almost identically to HTTP.
Maciej Stachowiak wrote:
On Aug 7, 2009, at 12:25 AM, Greg Wilkins wrote:
But if your starting point is a working HTTP client or server, then
the work needed to implement BWTP should not be too significant,
as the additional complexities (Header fields and mime encoded
content) are
On Fri, Aug 7, 2009 at 12:25 AM, Greg Wilkinsgr...@mortbay.com wrote:
Maciej Stachowiak wrote:
This proposal looks a bit more complicated than the WS protocol, so it
may take a bit to digest.
Maciej,
BWTP is indeed more complex that the base websocket protocol
I think this is one of the
Jonas,
taking some of your comments out of order
My gut feeling on BWTP vs. websocket is that BWTP carries some
unneccesary complexity/overhead by allowing arbitrary headers in each
frame, whereas websocket is unnecessarily low level.
I added the headers to BWTP (headers), because I
All,
on the IETF Hybi mailing list there has been some discussion regarding the
protocol that should carry WebSockets.
There was considerable divided opinions about the style of protocol that
would be most appropriate and what level of features should be supported
etc. That conversation ground
23 matches
Mail list logo
