[chromium-dev] Re: HTML5 Web Socket design doc

[鵜飼文敏]

2009/6/26 Michael Nordman micha...@google.com



 2009/6/25 Fumitoshi Ukai (鵜飼文敏) u...@chromium.org

 Thanks for review.

 2009/6/25 Michael Nordman micha...@google.com

 Only skimmed thusfar as well... but from what i've seen, looks reasonable
 to me.
 * A version of the diagram you have in the chrome doc would be nice in
 the webkit doc too.


 Sure.  I've added a diagram in webkit part.


 * Does WebSocketHandle really need to be refcounted. I know
 ResourceHandle is a refcounted object and this design looks modeled off of
 that (which may be why you've spec'd it this way). Unless your design
 actually needs refcounting on this class, you may be able to simplify things
 without it. From the looks of it, WebSocketChannel 'owns' the
 WebSocketHandle.


 Yes.  I missed to add public RefCountedWebSocketHandle as base class of
 WebSocketHandle.
  Thanks.


 I was suggesting that perhaps the WebSocketHandle does not need to be
 refcounted.


Oh, sorry.   I changed it to OwnPtr.





   should we reuse WebCore/loader instead of adding new component?

 The loader is somewhat notorious for its complexity. I think you've made
 a good decision to keep this out of there and to design the websocket system
 in a good clean modular fashion.

  which component is responsible of web socket protocol framing?  This
 design assumes WebSocketChannel serializes/deserializes message in web
 socket frame.

 Since WebSocketHandle is inevitably going to be platform specific, any
 code you want to be shared code shouldn't be slated for that class. To the
 extent the 'web socket protocol framing' can be done indepedent of the
 'platform' socket handle (which it looks like it can be), it would be a good
 thing to put it in WebSocketChannel so its shared core common code goodness.


 I see.
 I've one question: Web socket handshaking is also platform independent.
 Should we do the handshaking in WebSocketChannel and WebSocketHandle just
 provides almost raw TCP socket?
 Or Put handshaking in WebSocketHandle as resource loader puts HTTP in
 platform code?


 I haven't read the web sockets spec, so I don't know what the
  'handshaking' entails?


It looks something similar like HTTP request/response.
see  http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol more
details.

OS level socket creation/destruction and tcp connection opening/closing
 needs to be per-platform. Once you have a full-duplex connection and are
 sending application 'protocol' data back and forth (message framing), that
 probably wants to be common code. Which camp does the 'handshaking' fall
 into?


Hmm, maybe we need to move construction of request in web socket handshake,
and verification of response  in web socket handshake.  Updated.

Thanks!
ukai







  Regarding the WebKit API, note that no WebCore data types can be used
 there. So you'll need to create wrapper classes.

 I see you have speced WebKit:: wrapper classes with the same name as the
 corresponding WebCore:: classes.

 I wonder if that same naming could be confusingt? The naming convention
 darin has been employing would be WebKit::WebWebSocketHandle, which
 certainly looks odd.


 Ok.  I follow the naming convention to be WebKit::WebWebSocketHandle.


  * virtual void didReceiveData(const String msg) {}

 Maybe rename this to channel client api to didReceiveMessage() to help
 distinguish between raw 'data' being surface by the 'handle', and complete
 'messages' being surfaced by the 'channel'.


 Sure. Fixed.

 Thanks!
 ukai




 On Wed, Jun 24, 2009 at 2:32 AM, Fumitoshi Ukai (鵜飼文敏) 
 u...@chromium.org wrote:

 Hi,

 yuzo, tyoshino and I start working to implement HTML5 Web Socket and
 write design docs

  WebKit part: http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh
  Chromium part: http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm

 We'll send WebKit part to webkit-dev, if it looks ok.
 We'd welcome if you could give us feedback on our design docs.

 Thanks,
 ukai

 





--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: HTML5 Web Socket design doc

[鵜飼文敏]

Hi,
Thanks for review.

2009/6/25 Jeremy Orlow jor...@chromium.org

 I only skimmed, but it looks well thought out.
 One question though:
 is this going to be functional for non-Chromium browsers?  Given that your 
 design doc mentions v8 and hooks into Chromium's network
 stack, but no mention of JavaScriptCore or WebKit's resource loading code,
 I'm worried that the answer is no.




 I strongly recommend that your design doc include details for full
 integration into normal WebKit and that you offer to write the necessary
 code.  If it's Chromium only, you'll definitely get more push back on the
 design and people will be less willing to review.  Probably to the extent
 that it would have been easier to just write the code to begin with.


v8 and hooks into chromium's network stack was written in chromium part
only.
I planed to send webkit part to webkit-dev.
I've mentioned what platform code is required in WebSocketHandle in webkit
part design doc.
I just added JavaScript binding section.
Do we need more detailed information for these part?

Thanks,
ukai


 J

 On Wed, Jun 24, 2009 at 2:32 AM, Fumitoshi Ukai (鵜飼文敏) 
 u...@chromium.orgwrote:

 Hi,

 yuzo, tyoshino and I start working to implement HTML5 Web Socket and write
 design docs

  WebKit part: http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh
  Chromium part: http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm

 We'll send WebKit part to webkit-dev, if it looks ok.
 We'd welcome if you could give us feedback on our design docs.

 Thanks,
 ukai

 



--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: HTML5 Web Socket design doc

[鵜飼文敏]

Thanks for review.

2009/6/25 Michael Nordman micha...@google.com

 Only skimmed thusfar as well... but from what i've seen, looks reasonable
 to me.
 * A version of the diagram you have in the chrome doc would be nice in the
 webkit doc too.


Sure.  I've added a diagram in webkit part.


 * Does WebSocketHandle really need to be refcounted. I know ResourceHandle
 is a refcounted object and this design looks modeled off of that (which may
 be why you've spec'd it this way). Unless your design actually needs
 refcounting on this class, you may be able to simplify things without it.
 From the looks of it, WebSocketChannel 'owns' the WebSocketHandle.


Yes.  I missed to add public RefCountedWebSocketHandle as base class of
WebSocketHandle.
 Thanks.

 should we reuse WebCore/loader instead of adding new component?

 The loader is somewhat notorious for its complexity. I think you've made a
 good decision to keep this out of there and to design the websocket system
 in a good clean modular fashion.

  which component is responsible of web socket protocol framing?  This
 design assumes WebSocketChannel serializes/deserializes message in web
 socket frame.

 Since WebSocketHandle is inevitably going to be platform specific, any code
 you want to be shared code shouldn't be slated for that class. To the extent
 the 'web socket protocol framing' can be done indepedent of the 'platform'
 socket handle (which it looks like it can be), it would be a good thing to
 put it in WebSocketChannel so its shared core common code goodness.


I see.
I've one question: Web socket handshaking is also platform independent.
Should we do the handshaking in WebSocketChannel and WebSocketHandle just
provides almost raw TCP socket?
Or Put handshaking in WebSocketHandle as resource loader puts HTTP in
platform code?

 Regarding the WebKit API, note that no WebCore data types can be used
 there. So you'll need to create wrapper classes.

 I see you have speced WebKit:: wrapper classes with the same name as the
 corresponding WebCore:: classes.

 I wonder if that same naming could be confusingt? The naming convention
 darin has been employing would be WebKit::WebWebSocketHandle, which
 certainly looks odd.


Ok.  I follow the naming convention to be WebKit::WebWebSocketHandle.


 * virtual void didReceiveData(const String msg) {}

 Maybe rename this to channel client api to didReceiveMessage() to help
 distinguish between raw 'data' being surface by the 'handle', and complete
 'messages' being surfaced by the 'channel'.


Sure. Fixed.

Thanks!
ukai




 On Wed, Jun 24, 2009 at 2:32 AM, Fumitoshi Ukai (鵜飼文敏) 
 u...@chromium.orgwrote:

 Hi,

 yuzo, tyoshino and I start working to implement HTML5 Web Socket and write
 design docs

  WebKit part: http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh
  Chromium part: http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm

 We'll send WebKit part to webkit-dev, if it looks ok.
 We'd welcome if you could give us feedback on our design docs.

 Thanks,
 ukai

 



--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: HTML5 Web Socket design doc

[鵜飼文敏]

Hi,

2009/6/25 Drew Wilson atwil...@google.com

 BTW, I checked in with IanH - it sounds like WebSockets are also on the
 Worker roadmap, so that's something to keep in mind while you iterate on
 your design.


Ok, I see.


 +1 to avoiding WebCore/loader, but also +1 to refactoring to enable as much
 common code as possible cross-platform - I'm looking at the Chromium worker
 code now, and there's a chunk of duplicated logic from the WebKit worker
 implementation, which is a bit of a maintenance headache.


Sure.
-- 
ukai



 -atw

 2009/6/24 Michael Nordman micha...@google.com

 Only skimmed thusfar as well... but from what i've seen, looks reasonable
 to me.
 * A version of the diagram you have in the chrome doc would be nice in the
 webkit doc too.

 * Does WebSocketHandle really need to be refcounted. I know ResourceHandle
 is a refcounted object and this design looks modeled off of that (which may
 be why you've spec'd it this way). Unless your design actually needs
 refcounting on this class, you may be able to simplify things without it.
 From the looks of it, WebSocketChannel 'owns' the WebSocketHandle.

  should we reuse WebCore/loader instead of adding new component?

 The loader is somewhat notorious for its complexity. I think you've made a
 good decision to keep this out of there and to design the websocket system
 in a good clean modular fashion.

  which component is responsible of web socket protocol framing?  This
 design assumes WebSocketChannel serializes/deserializes message in web
 socket frame.

 Since WebSocketHandle is inevitably going to be platform specific, any
 code you want to be shared code shouldn't be slated for that class. To the
 extent the 'web socket protocol framing' can be done indepedent of the
 'platform' socket handle (which it looks like it can be), it would be a good
 thing to put it in WebSocketChannel so its shared core common code goodness.

  Regarding the WebKit API, note that no WebCore data types can be used
 there. So you'll need to create wrapper classes.

 I see you have speced WebKit:: wrapper classes with the same name as the
 corresponding WebCore:: classes.

 I wonder if that same naming could be confusingt? The naming convention
 darin has been employing would be WebKit::WebWebSocketHandle, which
 certainly looks odd.

 * virtual void didReceiveData(const String msg) {}

 Maybe rename this to channel client api to didReceiveMessage() to help
 distinguish between raw 'data' being surface by the 'handle', and complete
 'messages' being surfaced by the 'channel'.


 On Wed, Jun 24, 2009 at 2:32 AM, Fumitoshi Ukai (鵜飼文敏) u...@chromium.org
  wrote:

 Hi,

 yuzo, tyoshino and I start working to implement HTML5 Web Socket and
 write design docs

  WebKit part: http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh
  Chromium part: http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm

 We'll send WebKit part to webkit-dev, if it looks ok.
 We'd welcome if you could give us feedback on our design docs.

 Thanks,
 ukai




 



--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: HTML5 Web Socket design doc

[鵜飼文敏]

2009/6/25 Chris Evans cev...@google.com

 On Wed, Jun 24, 2009 at 2:32 AM, Fumitoshi Ukai (鵜飼文敏) 
 u...@chromium.orgwrote:

 Hi,

 yuzo, tyoshino and I start working to implement HTML5 Web Socket and write
 design docs

  WebKit part: http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh
  Chromium part: http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm

 We'll send WebKit part to webkit-dev, if it looks ok.
 We'd welcome if you could give us feedback on our design docs.


 Interesting feature :) It's hard to tell at first glance, because the
 security section is empty -- but it appears like security has been
 considered at least in
 http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-17.



 It might be worth being more explicit about security in our WebKit doc
 (i.e. creating a new security section).


Ok, I added the security section.
Anyway, the websocket protocol doc has security considerations section,
but no information there yet..


 Possible tests we'll want include:

 - Connect a web socket to some ordinary HTTP server and confirm that the
 connect fails.
 - Connect a web socket to a real web socket server that fails to return a
 websocket-origin header, and validate that the connect fails (if it didn't,
 a simple server bug could open up responses to all origins)
 - Check we respect the origin sent from the server.
 - What about redirectors? Assuming unsupported, verify that connecting to a
 redirector does not cause any redirection.
 - URL integration: what happens if a ws:// or wss:// URL is entered into
 the URL bar, or any other place an URL is accepted? (img tags, script tags
 etc).
 - What about embedded newline characters in the various strings the client
 gets to specify (URL, resource name, protocol etc). Ensure that no lines
 sent to the server can be caused to be split by doing this.
 - Length encoding: ensure we handle excessively long length encodings, e.g.
 0xff 0xff 0xff... ad infinitum. Test we can handle decoded lengths that
 happen to be negative (or very large) when assigned to int32, int64, uint32,
 uint64.
 - Cookies: ensure we _never_ transmit any HTTP cookies over the unencrypted
 ws:// channel, if that cookie was marked Secure. Similar test for
 Authorization headers.


Thanks for valuable test cases!  We'll test these case.

Thanks,
ukai



 Cheers
 Chris



 Thanks,
 ukai

 



--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: HTML5 Web Socket design doc

[坊野 博典]

Hi Ukai-san,

 ViewHostMsg_WebSocket*: IPC messages sent from renderer to browser.
 ViewHostMsg_WebSocketOpen: open a new Web Socket. called by 
 WebSocketHandle::connect().
 int request_id  // idenfity WebSocket object {GURL url, std::wstring 
 protocol, std::wstring origin, bool secure, [...]}
 ViewHostMsg_WebSocketSend: trasmit a frame containing data over the Web 
 Socket connection.  called by WebSocketHandle::send().
 int request_id  // Identify WebSocket object
 std::vectorunsigned char data
 ViewHostMsg_WebSocketDisconnect: disconnect the Web Socket connection. called 
 by WebSocketHandle destructor.
 int request_id  // Identify WebSocket object
 ViewMsg_WebSocket*: IPC messages sent from browser to renderer.
 ViewMsg_WebSocketConnect: New Web Socket connection is established. will call 
 WebSocketHandle::client()-didConnect().
 int request_id  // Identify WebSocket object
 ViewMsg_WebSocketRecv: a frame containing data is received on the Web Socket 
 connection. will add data into  WebSocketHandle::bufferedData().  Process 
 all complete Web Socket frames, call WebSocketHandle::client()-didReceive().
 int request_id  // Identify WebSocket object
 std::vectorunsigned char data
 ViewMsg_WebSocketClose: the Web Socket connection is closed (on the other 
 side).  will call WebSocketHandle::client()-didClose().
 int request_id  // Identify WebSocket object

I'm a little wondering whether  these messages are async messages or
sync ones. Is it possible to add notes about their message types?

Regards,

Hironori Bono
E-mail: hb...@chromium.org

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: HTML5 Web Socket design doc

[鵜飼文敏]

Hi,

2009/6/25 Hironori Bono (坊野 博典) hb...@chromium.org

 Hi Ukai-san,

  ViewHostMsg_WebSocket*: IPC messages sent from renderer to browser.
  ViewHostMsg_WebSocketOpen: open a new Web Socket. called by
 WebSocketHandle::connect().
  int request_id  // idenfity WebSocket object {GURL url, std::wstring
 protocol, std::wstring origin, bool secure, [...]}
  ViewHostMsg_WebSocketSend: trasmit a frame containing data over the Web
 Socket connection.  called by WebSocketHandle::send().
  int request_id  // Identify WebSocket object
  std::vectorunsigned char data
  ViewHostMsg_WebSocketDisconnect: disconnect the Web Socket connection.
 called by WebSocketHandle destructor.
  int request_id  // Identify WebSocket object
  ViewMsg_WebSocket*: IPC messages sent from browser to renderer.
  ViewMsg_WebSocketConnect: New Web Socket connection is established. will
 call WebSocketHandle::client()-didConnect().
  int request_id  // Identify WebSocket object
  ViewMsg_WebSocketRecv: a frame containing data is received on the Web
 Socket connection. will add data into  WebSocketHandle::bufferedData().
  Process all complete Web Socket frames, call
 WebSocketHandle::client()-didReceive().
  int request_id  // Identify WebSocket object
  std::vectorunsigned char data
  ViewMsg_WebSocketClose: the Web Socket connection is closed (on the other
 side).  will call WebSocketHandle::client()-didClose().
  int request_id  // Identify WebSocket object

 I'm a little wondering whether  these messages are async messages or
 sync ones. Is it possible to add notes about their message types?


Yes.  I think all of these messages are routed and async messages.
Thanks for pointing it out.
-- 
ukai




 Regards,

 Hironori Bono
 E-mail: hb...@chromium.org


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: HTML5 Web Socket design doc

[John Abd-El-Malek]

2009/6/25 Fumitoshi Ukai (鵜飼文敏) u...@chromium.org

 Thanks for review.

 2009/6/25 Michael Nordman micha...@google.com

 Only skimmed thusfar as well... but from what i've seen, looks reasonable
 to me.
 * A version of the diagram you have in the chrome doc would be nice in the
 webkit doc too.


 Sure.  I've added a diagram in webkit part.


 * Does WebSocketHandle really need to be refcounted. I know ResourceHandle
 is a refcounted object and this design looks modeled off of that (which may
 be why you've spec'd it this way). Unless your design actually needs
 refcounting on this class, you may be able to simplify things without it.
 From the looks of it, WebSocketChannel 'owns' the WebSocketHandle.


 Yes.  I missed to add public RefCountedWebSocketHandle as base class of
 WebSocketHandle.
  Thanks.

   should we reuse WebCore/loader instead of adding new component?

 The loader is somewhat notorious for its complexity. I think you've made a
 good decision to keep this out of there and to design the websocket system
 in a good clean modular fashion.

  which component is responsible of web socket protocol framing?  This
 design assumes WebSocketChannel serializes/deserializes message in web
 socket frame.

 Since WebSocketHandle is inevitably going to be platform specific, any
 code you want to be shared code shouldn't be slated for that class. To the
 extent the 'web socket protocol framing' can be done indepedent of the
 'platform' socket handle (which it looks like it can be), it would be a good
 thing to put it in WebSocketChannel so its shared core common code goodness.


 I see.
 I've one question: Web socket handshaking is also platform independent.
 Should we do the handshaking in WebSocketChannel and WebSocketHandle just
 provides almost raw TCP socket?
 Or Put handshaking in WebSocketHandle as resource loader puts HTTP in
 platform code?

  Regarding the WebKit API, note that no WebCore data types can be used
 there. So you'll need to create wrapper classes.


The WebKit API classes still derive from WebCore, which isn't possible.  The
WebKit API is an abstraction around WebCore classes, so it can't use any
WebCore types in it.


 I see you have speced WebKit:: wrapper classes with the same name as the
 corresponding WebCore:: classes.

 I wonder if that same naming could be confusingt? The naming convention
 darin has been employing would be WebKit::WebWebSocketHandle, which
 certainly looks odd.


 Ok.  I follow the naming convention to be WebKit::WebWebSocketHandle.


hmm, I actually find WebWeb very unwieldy.  I vote for
WebKit::WebSocketHandle.




  * virtual void didReceiveData(const String msg) {}

 Maybe rename this to channel client api to didReceiveMessage() to help
 distinguish between raw 'data' being surface by the 'handle', and complete
 'messages' being surfaced by the 'channel'.


 Sure. Fixed.

 Thanks!
 ukai




 On Wed, Jun 24, 2009 at 2:32 AM, Fumitoshi Ukai (鵜飼文敏) u...@chromium.org
  wrote:

 Hi,

 yuzo, tyoshino and I start working to implement HTML5 Web Socket and
 write design docs

  WebKit part: http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh
  Chromium part: http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm

 We'll send WebKit part to webkit-dev, if it looks ok.
 We'd welcome if you could give us feedback on our design docs.

 Thanks,
 ukai





 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: HTML5 Web Socket design doc

[Michael Nordman]

2009/6/25 Fumitoshi Ukai (鵜飼文敏) u...@chromium.org

 Thanks for review.

 2009/6/25 Michael Nordman micha...@google.com

 Only skimmed thusfar as well... but from what i've seen, looks reasonable
 to me.
 * A version of the diagram you have in the chrome doc would be nice in the
 webkit doc too.


 Sure.  I've added a diagram in webkit part.


 * Does WebSocketHandle really need to be refcounted. I know ResourceHandle
 is a refcounted object and this design looks modeled off of that (which may
 be why you've spec'd it this way). Unless your design actually needs
 refcounting on this class, you may be able to simplify things without it.
 From the looks of it, WebSocketChannel 'owns' the WebSocketHandle.


 Yes.  I missed to add public RefCountedWebSocketHandle as base class of
 WebSocketHandle.
  Thanks.


I was suggesting that perhaps the WebSocketHandle does not need to be
refcounted.




   should we reuse WebCore/loader instead of adding new component?

 The loader is somewhat notorious for its complexity. I think you've made a
 good decision to keep this out of there and to design the websocket system
 in a good clean modular fashion.

  which component is responsible of web socket protocol framing?  This
 design assumes WebSocketChannel serializes/deserializes message in web
 socket frame.

 Since WebSocketHandle is inevitably going to be platform specific, any
 code you want to be shared code shouldn't be slated for that class. To the
 extent the 'web socket protocol framing' can be done indepedent of the
 'platform' socket handle (which it looks like it can be), it would be a good
 thing to put it in WebSocketChannel so its shared core common code goodness.


 I see.
 I've one question: Web socket handshaking is also platform independent.
 Should we do the handshaking in WebSocketChannel and WebSocketHandle just
 provides almost raw TCP socket?
 Or Put handshaking in WebSocketHandle as resource loader puts HTTP in
 platform code?


I haven't read the web sockets spec, so I don't know what the  'handshaking'
entails?

OS level socket creation/destruction and tcp connection opening/closing
needs to be per-platform. Once you have a full-duplex connection and are
sending application 'protocol' data back and forth (message framing), that
probably wants to be common code. Which camp does the 'handshaking' fall
into?






  Regarding the WebKit API, note that no WebCore data types can be used
 there. So you'll need to create wrapper classes.

 I see you have speced WebKit:: wrapper classes with the same name as the
 corresponding WebCore:: classes.

 I wonder if that same naming could be confusingt? The naming convention
 darin has been employing would be WebKit::WebWebSocketHandle, which
 certainly looks odd.


 Ok.  I follow the naming convention to be WebKit::WebWebSocketHandle.


  * virtual void didReceiveData(const String msg) {}

 Maybe rename this to channel client api to didReceiveMessage() to help
 distinguish between raw 'data' being surface by the 'handle', and complete
 'messages' being surfaced by the 'channel'.


 Sure. Fixed.

 Thanks!
 ukai




 On Wed, Jun 24, 2009 at 2:32 AM, Fumitoshi Ukai (鵜飼文敏) u...@chromium.org
  wrote:

 Hi,

 yuzo, tyoshino and I start working to implement HTML5 Web Socket and
 write design docs

  WebKit part: http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh
  Chromium part: http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm

 We'll send WebKit part to webkit-dev, if it looks ok.
 We'd welcome if you could give us feedback on our design docs.

 Thanks,
 ukai

 




--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: HTML5 Web Socket design doc

[鵜飼文敏]

2009/6/26 John Abd-El-Malek j...@chromium.org



 2009/6/25 Fumitoshi Ukai (鵜飼文敏) u...@chromium.org

 Thanks for review.

 2009/6/25 Michael Nordman micha...@google.com

 Only skimmed thusfar as well... but from what i've seen, looks reasonable
 to me.
 * A version of the diagram you have in the chrome doc would be nice in
 the webkit doc too.


 Sure.  I've added a diagram in webkit part.


 * Does WebSocketHandle really need to be refcounted. I know
 ResourceHandle is a refcounted object and this design looks modeled off of
 that (which may be why you've spec'd it this way). Unless your design
 actually needs refcounting on this class, you may be able to simplify things
 without it. From the looks of it, WebSocketChannel 'owns' the
 WebSocketHandle.


 Yes.  I missed to add public RefCountedWebSocketHandle as base class of
 WebSocketHandle.
  Thanks.

   should we reuse WebCore/loader instead of adding new component?

 The loader is somewhat notorious for its complexity. I think you've made
 a good decision to keep this out of there and to design the websocket system
 in a good clean modular fashion.

  which component is responsible of web socket protocol framing?  This
 design assumes WebSocketChannel serializes/deserializes message in web
 socket frame.

 Since WebSocketHandle is inevitably going to be platform specific, any
 code you want to be shared code shouldn't be slated for that class. To the
 extent the 'web socket protocol framing' can be done indepedent of the
 'platform' socket handle (which it looks like it can be), it would be a good
 thing to put it in WebSocketChannel so its shared core common code goodness.


 I see.
 I've one question: Web socket handshaking is also platform independent.
 Should we do the handshaking in WebSocketChannel and WebSocketHandle just
 provides almost raw TCP socket?
 Or Put handshaking in WebSocketHandle as resource loader puts HTTP in
 platform code?

  Regarding the WebKit API, note that no WebCore data types can be used
 there. So you'll need to create wrapper classes.


 The WebKit API classes still derive from WebCore, which isn't possible.
  The WebKit API is an abstraction around WebCore classes, so it can't use
 any WebCore types in it.


Ah, Ok.  I updated WebKit API part not to use WebCore classes.




 I see you have speced WebKit:: wrapper classes with the same name as the
 corresponding WebCore:: classes.

 I wonder if that same naming could be confusingt? The naming convention
 darin has been employing would be WebKit::WebWebSocketHandle, which
 certainly looks odd.


 Ok.  I follow the naming convention to be WebKit::WebWebSocketHandle.


 hmm, I actually find WebWeb very unwieldy.  I vote for
 WebKit::WebSocketHandle.


Ok.  will use WebKit:;WebSocketHandle.


Thanks!
ukai





  * virtual void didReceiveData(const String msg) {}

 Maybe rename this to channel client api to didReceiveMessage() to help
 distinguish between raw 'data' being surface by the 'handle', and complete
 'messages' being surfaced by the 'channel'.


 Sure. Fixed.

 Thanks!
 ukai




 On Wed, Jun 24, 2009 at 2:32 AM, Fumitoshi Ukai (鵜飼文敏) 
 u...@chromium.org wrote:

 Hi,

 yuzo, tyoshino and I start working to implement HTML5 Web Socket and
 write design docs

  WebKit part: http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh
  Chromium part: http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm

 We'll send WebKit part to webkit-dev, if it looks ok.
 We'd welcome if you could give us feedback on our design docs.

 Thanks,
 ukai





 



--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: HTML5 Web Socket design doc

[Jeremy Orlow]

I only skimmed, but it looks well thought out.
One question though:
is this going to be functional for non-Chromium browsers?  Given that
your design doc mentions v8 and hooks into Chromium's network
stack, but no mention of JavaScriptCore or WebKit's resource loading code,
I'm worried that the answer is no.

I strongly recommend that your design doc include details for full
integration into normal WebKit and that you offer to write the necessary
code.  If it's Chromium only, you'll definitely get more push back on the
design and people will be less willing to review.  Probably to the extent
that it would have been easier to just write the code to begin with.

J

On Wed, Jun 24, 2009 at 2:32 AM, Fumitoshi Ukai (鵜飼文敏) u...@chromium.orgwrote:

 Hi,

 yuzo, tyoshino and I start working to implement HTML5 Web Socket and write
 design docs

  WebKit part: http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh
  Chromium part: http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm

 We'll send WebKit part to webkit-dev, if it looks ok.
 We'd welcome if you could give us feedback on our design docs.

 Thanks,
 ukai

 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: HTML5 Web Socket design doc

[John Abd-El-Malek]

On Wed, Jun 24, 2009 at 2:32 AM, Fumitoshi Ukai (鵜飼文敏) u...@chromium.orgwrote:

 Hi,

 yuzo, tyoshino and I start working to implement HTML5 Web Socket and write
 design docs

  WebKit part: http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh
  Chromium part: http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm


Regarding the WebKit API, note that no WebCore data types can be used
there.  So you'll need to create wrapper classes that use data types
available in the WebKit API (i.e. WebUrl, WebString).


 http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm

 We'll send WebKit part to webkit-dev, if it looks ok.
 We'd welcome if you could give us feedback on our design docs.

 Thanks,
 ukai

 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: HTML5 Web Socket design doc

[Michael Nordman]

Only skimmed thusfar as well... but from what i've seen, looks reasonable to
me.
* A version of the diagram you have in the chrome doc would be nice in the
webkit doc too.

* Does WebSocketHandle really need to be refcounted. I know ResourceHandle
is a refcounted object and this design looks modeled off of that (which may
be why you've spec'd it this way). Unless your design actually needs
refcounting on this class, you may be able to simplify things without it.
From the looks of it, WebSocketChannel 'owns' the WebSocketHandle.

 should we reuse WebCore/loader instead of adding new component?

The loader is somewhat notorious for its complexity. I think you've made a
good decision to keep this out of there and to design the websocket system
in a good clean modular fashion.

 which component is responsible of web socket protocol framing?  This
design assumes WebSocketChannel serializes/deserializes message in web
socket frame.

Since WebSocketHandle is inevitably going to be platform specific, any code
you want to be shared code shouldn't be slated for that class. To the extent
the 'web socket protocol framing' can be done indepedent of the 'platform'
socket handle (which it looks like it can be), it would be a good thing to
put it in WebSocketChannel so its shared core common code goodness.

 Regarding the WebKit API, note that no WebCore data types can be used
there. So you'll need to create wrapper classes.

I see you have speced WebKit:: wrapper classes with the same name as the
corresponding WebCore:: classes.

I wonder if that same naming could be confusingt? The naming convention
darin has been employing would be WebKit::WebWebSocketHandle, which
certainly looks odd.

* virtual void didReceiveData(const String msg) {}

Maybe rename this to channel client api to didReceiveMessage() to help
distinguish between raw 'data' being surface by the 'handle', and complete
'messages' being surfaced by the 'channel'.


On Wed, Jun 24, 2009 at 2:32 AM, Fumitoshi Ukai (鵜飼文敏) u...@chromium.orgwrote:

 Hi,

 yuzo, tyoshino and I start working to implement HTML5 Web Socket and write
 design docs

  WebKit part: http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh
  Chromium part: http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm

 We'll send WebKit part to webkit-dev, if it looks ok.
 We'd welcome if you could give us feedback on our design docs.

 Thanks,
 ukai

 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: HTML5 Web Socket design doc

[Drew Wilson]

BTW, I checked in with IanH - it sounds like WebSockets are also on the
Worker roadmap, so that's something to keep in mind while you iterate on
your design.
+1 to avoiding WebCore/loader, but also +1 to refactoring to enable as much
common code as possible cross-platform - I'm looking at the Chromium worker
code now, and there's a chunk of duplicated logic from the WebKit worker
implementation, which is a bit of a maintenance headache.

-atw

2009/6/24 Michael Nordman micha...@google.com

 Only skimmed thusfar as well... but from what i've seen, looks reasonable
 to me.
 * A version of the diagram you have in the chrome doc would be nice in the
 webkit doc too.

 * Does WebSocketHandle really need to be refcounted. I know ResourceHandle
 is a refcounted object and this design looks modeled off of that (which may
 be why you've spec'd it this way). Unless your design actually needs
 refcounting on this class, you may be able to simplify things without it.
 From the looks of it, WebSocketChannel 'owns' the WebSocketHandle.

  should we reuse WebCore/loader instead of adding new component?

 The loader is somewhat notorious for its complexity. I think you've made a
 good decision to keep this out of there and to design the websocket system
 in a good clean modular fashion.

  which component is responsible of web socket protocol framing?  This
 design assumes WebSocketChannel serializes/deserializes message in web
 socket frame.

 Since WebSocketHandle is inevitably going to be platform specific, any code
 you want to be shared code shouldn't be slated for that class. To the extent
 the 'web socket protocol framing' can be done indepedent of the 'platform'
 socket handle (which it looks like it can be), it would be a good thing to
 put it in WebSocketChannel so its shared core common code goodness.

  Regarding the WebKit API, note that no WebCore data types can be used
 there. So you'll need to create wrapper classes.

 I see you have speced WebKit:: wrapper classes with the same name as the
 corresponding WebCore:: classes.

 I wonder if that same naming could be confusingt? The naming convention
 darin has been employing would be WebKit::WebWebSocketHandle, which
 certainly looks odd.

 * virtual void didReceiveData(const String msg) {}

 Maybe rename this to channel client api to didReceiveMessage() to help
 distinguish between raw 'data' being surface by the 'handle', and complete
 'messages' being surfaced by the 'channel'.


 On Wed, Jun 24, 2009 at 2:32 AM, Fumitoshi Ukai (鵜飼文敏) 
 u...@chromium.orgwrote:

 Hi,

 yuzo, tyoshino and I start working to implement HTML5 Web Socket and write
 design docs

  WebKit part: http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh
  Chromium part: http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm

 We'll send WebKit part to webkit-dev, if it looks ok.
 We'd welcome if you could give us feedback on our design docs.

 Thanks,
 ukai




 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: HTML5 Web Socket design doc

[Drew Wilson]

Also, it occurs to me that I can avoid making the problem worse by not
putting the MessagePort entanglement in the proxy layer, which my patch
currently does (ick). Proving that proper API design does enable better code
re-use :)
-atw taking my own advice

2009/6/24 John Abd-El-Malek j...@chromium.org



 2009/6/24 Drew Wilson atwil...@google.com

 I'm looking at the code in webworker_impl.cc and webworkerclient_impl.cpp,
 vs the code in WebCore/workers/WorkerMessagingProxy.cpp.
 As an example:

 Chrome version:
  void WebWorkerClientImpl::postMessageToWorkerContext(
 const WebCore::String message) {
   // Worker.terminate() could be called from JS before the context is
 started.
   if (asked_to_terminate_)
 return;

   ++unconfirmed_message_count_;

   if (!WTF::isMainThread()) {
 WebWorkerImpl::DispatchTaskToMainThread(
 WebCore::createCallbackTask(PostMessageToWorkerContextTask, this,
 message));
 return;
   }
   webworker_-postMessageToWorkerContext(
   webkit_glue::StringToWebString(message));
 }

  WebKit version:
 void WorkerMessagingProxy::postMessageToWorkerContext(const String
 message)
 {
 if (m_askedToTerminate)
 return;

 if (m_workerThread) {
 ++m_unconfirmedMessageCount;

  
 m_workerThread-runLoop().postTask(MessageWorkerContextTask::create(message));
 } else

  m_queuedEarlyTasks.append(MessageWorkerContextTask::create(message));
 }


 The duplications become even more apparent as I evolve these APIs to
 support MessagePorts. I'm just seeing similar logic (checking for terminated
 tasks, tracking undelivered messages, and soon disentangling message ports
 and dealing with errors) that has to be updated in parallel in both trees.

 Not a big deal, either way. Now that the Chrome implementation is pretty
 stable, we might want to refactor the WorkerProxy APIs to see if we can
 share more code across implementations.


 It'd be great of course if unconfirmed_message_count_
 and asked_to_terminate_ weren't needed, but it's used to avoid a large
 number of cross process calls (the equivalent variables in WebKit would be
 in a different process).  Almost all the rest of the file is converting back
 and forth between WebCore and Chrome data types in the glue layer, which is
 a necessary pain.


 -atw

 2009/6/24 John Abd-El-Malek j...@chromium.org



 2009/6/24 Drew Wilson atwil...@chromium.org

 BTW, I checked in with IanH - it sounds like WebSockets are also on the
 Worker roadmap, so that's something to keep in mind while you iterate on
 your design.
 +1 to avoiding WebCore/loader, but also +1 to refactoring to enable as
 much common code as possible cross-platform - I'm looking at the Chromium
 worker code now, and there's a chunk of duplicated logic from the WebKit
 worker implementation, which is a bit of a maintenance headache.


 I'm curious, which parts of the code are you talking about?



 -atw

 2009/6/24 Michael Nordman micha...@google.com

 Only skimmed thusfar as well... but from what i've seen, looks
 reasonable to me.
 * A version of the diagram you have in the chrome doc would be nice in
 the webkit doc too.

 * Does WebSocketHandle really need to be refcounted. I know
 ResourceHandle is a refcounted object and this design looks modeled off of
 that (which may be why you've spec'd it this way). Unless your design
 actually needs refcounting on this class, you may be able to simplify 
 things
 without it. From the looks of it, WebSocketChannel 'owns' the
 WebSocketHandle.

  should we reuse WebCore/loader instead of adding new component?

 The loader is somewhat notorious for its complexity. I think you've
 made a good decision to keep this out of there and to design the websocket
 system in a good clean modular fashion.

  which component is responsible of web socket protocol framing?  This
 design assumes WebSocketChannel serializes/deserializes message in web
 socket frame.

 Since WebSocketHandle is inevitably going to be platform specific, any
 code you want to be shared code shouldn't be slated for that class. To the
 extent the 'web socket protocol framing' can be done indepedent of the
 'platform' socket handle (which it looks like it can be), it would be a 
 good
 thing to put it in WebSocketChannel so its shared core common code 
 goodness.

  Regarding the WebKit API, note that no WebCore data types can be
 used there. So you'll need to create wrapper classes.

 I see you have speced WebKit:: wrapper classes with the same name as
 the corresponding WebCore:: classes.

 I wonder if that same naming could be confusingt? The naming convention
 darin has been employing would be WebKit::WebWebSocketHandle, which
 certainly looks odd.

 * virtual void didReceiveData(const String msg) {}

 Maybe rename this to channel client api to didReceiveMessage() to help
 distinguish between raw 'data' being surface by the 'handle', and complete
 'messages' being surfaced by the 'channel'.


 On Wed, Jun 24, 2009 at 

[chromium-dev] Re: HTML5 Web Socket design doc

[Chris Evans]

On Jun 24, 2:32 am, Fumitoshi Ukai (鵜飼文敏) u...@chromium.org wrote:
 Hi,

 yuzo, tyoshino and I start working to implement HTML5 Web Socket and write
 design docs

  WebKit part:http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh
  Chromium part:http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm

 We'll send WebKit part to webkit-dev, if it looks ok.
 We'd welcome if you could give us feedback on our design docs.

Interesting feature :) It's hard to tell at first glance, because the
security section is empty -- but it appears like security has been
considered at least in 
http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-17.

It might be worth being more explicit about security in our WebKit doc
(i.e. creating a new security section). Possible tests we'll want
include:

- Connect a web socket to some ordinary HTTP server and confirm that
the connect fails.
- Connect a web socket to a real web socket server that fails to
return a websocket-origin header, and validate that the connect fails
(if it didn't, a simple server bug could open up responses to all
origins)
- Check we respect the origin sent from the server.
- What about redirectors? Assuming unsupported, verify that connecting
to a redirector does not cause any redirection.
- URL integration: what happens if a ws:// or wss:// URL is entered
into the URL bar, or any other place an URL is accepted? (img tags,
script tags etc).
- What about embedded newline characters in the various strings the
client gets to specify (URL, resource name, protocol etc). Ensure that
no lines sent to the server can be caused to be split by doing this.
- Length encoding: ensure we handle excessively long length encodings,
e.g. 0xff 0xff 0xff... ad infinitum. Test we can handle decoded
lengths that happen to be negative (or very large) when assigned to
int32, int64, uint32, uint64.
- Cookies: ensure we _never_ transmit any HTTP cookies over the
unencrypted ws:// channel, if that cookie was marked Secure. Similar
test for Authorization headers.


Cheers
Chris



 Thanks,
 ukai

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: HTML5 Web Socket design doc

[Chris Evans]

On Jun 24, 2:32 am, Fumitoshi Ukai (鵜飼文敏) u...@chromium.org wrote:
 Hi,

 yuzo, tyoshino and I start working to implement HTML5 Web Socket and write
 design docs

  WebKit part:http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh
  Chromium part:http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm

 We'll send WebKit part to webkit-dev, if it looks ok.
 We'd welcome if you could give us feedback on our design docs.

Interesting feature :) It's hard to tell at first glance, because the
security section is empty -- but it appears like security has been
considered at least in 
http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-17.

It might be worth being more explicit about security in our WebKit doc
(i.e. creating a new security section). Possible tests we'll want
include:

- Connect a web socket to some ordinary HTTP server and confirm that
the connect fails.
- Connect a web socket to a real web socket server that fails to
return a websocket-origin header, and validate that the connect fails
(if it didn't, a simple server bug could open up responses to all
origins)
- Check we respect the origin sent from the server.
- What about redirectors? Assuming unsupported, verify that connecting
to a redirector does not cause any redirection.
- URL integration: what happens if a ws:// or wss:// URL is entered
into the URL bar, or any other place an URL is accepted? (img tags,
script tags etc).
- What about embedded newline characters in the various strings the
client gets to specify (URL, resource name, protocol etc). Ensure that
no lines sent to the server can be caused to be split by doing this.
- Length encoding: ensure we handle excessively long length encodings,
e.g. 0xff 0xff 0xff... ad infinitum. Test we can handle decoded
lengths that happen to be negative (or very large) when assigned to
int32, int64, uint32, uint64.
- Cookies: ensure we _never_ transmit any HTTP cookies over the
unencrypted ws:// channel, if that cookie was marked Secure. Similar
test for Authorization headers.


Cheers
Chris


 Thanks,
 ukai

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: HTML5 Web Socket design doc

[Chris Evans]

On Jun 24, 2:32 am, Fumitoshi Ukai (鵜飼文敏) u...@chromium.org wrote:
 Hi,

 yuzo, tyoshino and I start working to implement HTML5 Web Socket and write
 design docs

  WebKit part:http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh
  Chromium part:http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm

 We'll send WebKit part to webkit-dev, if it looks ok.
 We'd welcome if you could give us feedback on our design docs.

Interesting feature :) It's hard to tell at first glance, because the
security section is empty -- but it appears like security has been
considered at least in 
http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-17.

It might be worth being more explicit about security in our WebKit doc
(i.e. creating a new security section). Possible tests we'll want
include:

- Connect a web socket to some ordinary HTTP server and confirm that
the connect fails.
- Connect a web socket to a real web socket server that fails to
return a websocket-origin header, and validate that the connect fails
(if it didn't, a simple server bug could open up responses to all
origins)
- Check we respect the origin sent from the server.
- What about redirectors? Assuming unsupported, verify that connecting
to a redirector does not cause any redirection.
- URL integration: what happens if a ws:// or wss:// URL is entered
into the URL bar, or any other place an URL is accepted? (img tags,
script tags etc).
- What about embedded newline characters in the various strings the
client gets to specify (URL, resource name, protocol etc). Ensure that
no lines sent to the server can be caused to be split by doing this.
- Length encoding: ensure we handle excessively long length encodings,
e.g. 0xff 0xff 0xff... ad infinitum. Test we can handle decoded
lengths that happen to be negative (or very large) when assigned to
int32, int64, uint32, uint64.
- Cookies: ensure we _never_ transmit any HTTP cookies over the
unencrypted ws:// channel, if that cookie was marked Secure. Similar
test for Authorization headers.


Cheers
Chris


 Thanks,
 ukai

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---