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

[鵜飼文敏]

2009/6/26 Michael Nordman 

>
>
> 2009/6/25 Fumitoshi Ukai (鵜飼文敏) 
>
>> Thanks for review.
>>
>> 2009/6/25 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.
>>>
>>
>> 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 RefCounted 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

[鵜飼文敏]

2009/6/26 John Abd-El-Malek 

>
>
> 2009/6/25 Fumitoshi Ukai (鵜飼文敏) 
>
>> Thanks for review.
>>
>> 2009/6/25 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.
>>>
>>
>> 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 RefCounted 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

[Michael Nordman]

2009/6/25 Fumitoshi Ukai (鵜飼文敏) 

> Thanks for review.
>
> 2009/6/25 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.
>>
>
> 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 RefCounted 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 (鵜飼文敏) > > 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

[John Abd-El-Malek]

2009/6/25 Fumitoshi Ukai (鵜飼文敏) 

> Thanks for review.
>
> 2009/6/25 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.
>>
>
> 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 RefCounted 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 (鵜飼文敏) > > 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,

2009/6/25 Hironori Bono (坊野 博典) 

> 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::vector 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::vector 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

[坊野 博典]

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::vector 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::vector 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

[鵜飼文敏]

2009/6/25 Chris Evans 

> On Wed, Jun 24, 2009 at 2:32 AM, Fumitoshi Ukai (鵜飼文敏) 
> 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).
>

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,

2009/6/25 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.


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 
>
> 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 (鵜飼文敏) > > 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

[鵜飼文敏]

Thanks for review.

2009/6/25 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.
>

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 RefCounted 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 (鵜飼文敏) 
> 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 

> 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 (鵜飼文敏) 
> 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

[Chris Evans]

On Jun 24, 2:32 am, Fumitoshi Ukai (鵜飼文敏)  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 (鵜飼文敏)  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 (鵜飼文敏)  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

[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 

>
>
> 2009/6/24 Drew Wilson 
>
> 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 
>>
>>
>>>
>>> 2009/6/24 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.

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

 -atw

 2009/6/24 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::WebWebSocket

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

[John Abd-El-Malek]

2009/6/24 Drew Wilson 

> 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 
>
>
>>
>> 2009/6/24 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.
>>>
>>
>> I'm curious, which parts of the code are you talking about?
>>
>>
>>>
>>> -atw
>>>
>>> 2009/6/24 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.org> wrote:

>

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

[John Abd-El-Malek]

2009/6/24 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.
>

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


>
> -atw
>
> 2009/6/24 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 (鵜飼文敏) > > 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

[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 

> 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 (鵜飼文敏) 
> 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]

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 (鵜飼文敏) 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

[John Abd-El-Malek]

On Wed, Jun 24, 2009 at 2:32 AM, Fumitoshi Ukai (鵜飼文敏) 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


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).


> 
>
> 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 (鵜飼文敏) 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
-~--~~~~--~~--~--~---