Jamie Lokier wrote:
Greg Wilkins wrote:
send the following bytes to the remote server
47 45 54 20
A literal reading of the spec would interpret that as
meaning that the bytes actually have to be sent, while
any sane implementation is going to append the bytes to
a buffer to be sent
Sorry for the cross post hybi/whatwg.
I raised these issues on hybi list, but there was no
specific response (probably due to the other issues
being debated there).
I think the issues below indicate ambiguities in the
spec. I raised them as an argument to change away from
the algorithmic style
Fumitoshi Ukai (鵜飼文敏) wrote:
On Thu, Nov 19, 2009 at 1:00 PM, Greg Wilkins gr...@webtide.com
var ws = new WebSocket(ws://mysite.com
http://mysite.com,myprotocol);
...
So if the next line in the script is
ws.onopen=myopenfunc;
there is a race between if the onopen
attempts to achieve the functionality and
scalability required by serious web applications.
On Fri, 4 Sep 2009, Greg Wilkins wrote:
The server on the server-side could hide the details from the server
side developer.
The server-side developer is the one writing the server.
With HTTP
WenboZhu wrote:
While the concerns on the server-side are overstated, the analogy to http is
also questionable ... The current protocol, being a *scoket* layer protocol,
is in principle different than http, which is strictly a L7 RPC protocol.
Wenbo,
TCP/IP does not map well to OSI layer
Ian Hickson wrote:
On Fri, 14 Aug 2009, Jeremy Orlow wrote:
On Fri, Aug 14, 2009 at 3:45 AM, Ian Hickson i...@hixie.ch wrote:
On Fri, 7 Aug 2009, Jonas Sicking wrote:
What would the API look like?
It seems like it could be done transparently to the web developer. If
you open 2
All,
thanks for the useful feedback on the BWTP proposal.
It was clear that while the features (such as meta-data and multi-plexing) were
welcome, the proposal was perhaps too complex.
I've written a second draft of the proposal
http://bwtp.wikidot.com/main:proposal1
I have simplified this
to improve websocket protocol that
was rejected:
Greg Wilkins wrote:
It would be great if the websocket proposal could include
standard definitions for mime encoded datagrams.
Current frame types are:
0x00 - sentinel framed UTF-8 message
0x80 - length framed binary data.
I'd like to see
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)
with bidirectional protocols.
regards
Example proposal to improve websocket protocol that
was rejected:
Greg Wilkins wrote:
It would be great if the websocket proposal could include
standard definitions for mime encoded datagrams.
Current frame types are:
0x00 - sentinel framed UTF-8
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,
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,
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
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
16 matches
Mail list logo
