[Webkit-unassigned] [Bug 72016] [Chromium] [WebSocket] export WebSocketChannel interface for plugins

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=72016





--- Comment #15 from Darin Fisher (:fishd, Google) <fishd at chromium.org>  2011-11-16 14:29:55 PST ---
(In reply to comment #7)
> Now, I try to rename it as WebKit::WebSocketChannel and WebKit::WebSocketChannelClient.
> But I have a name confliction problem.
> 
> We can access the lower prioritized header by #include_next directive. But, the directive is not used in WebKit now.
> 
> Fortunately, WebKit public headers have higher priority than WebCore headers.
> And WebCore files can be accessed with 'websockets/' prefix like #include "websockets/WebSocketChannel.h".
> But, in both cases, we must have another policy on ifdef idiom which is used to avoid duplicated include on the head of header files.
> The first WebSocketChannel_h definition disallow to include the second one. It means we must define another unique name for public headers.
> 
> Do you have any idea on that?
> For now, I keep class names unchanged in the next change.

Wow, that's really unfortunate.  Normally, WebCore stuff does not use the Web* prefix.  I wish we could just call the WebCore types SocketChannel, dropping the Web prefix there.  But, assuming that is not possible, then how about just using a different name for the WebKit API?  Maybe you could just call this WebSocket?

I realize that WebCore also defines WebSocket, but it looks like that may not cause a conflict here since you are only exposing the lower-level WebSocketChannel functionality.  To the embedder, referring to the channel as a WebSocket won't seem strange.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.