Re: WebSockets API

Hi,

Thanks for the reply.

On Tuesday 27 Nov 2012 09:04:11 Wolfgang Schnerring wrote:

> I'm not too familiar with WebSocket internals, but one thing that stuck
> with me is that you'll need to keep *lots* of open connections, which is
> only feasible with an eventloop-based server (which zope.server, for
> one, isn't).

Oh. That's an interesting point... I'm no expert either, but have seen them 
mentioned a lot recently, and started looking through the RFC the other day.

> 
> Apart from that, I'm not sure what features remain, and where a proper
> home in the ZTK world would be.

As I use grok, I had a little dig in grok's dependencies, and thought that 
zope.publisher.ws could be an appropriate home. I branched zope.publisher from 
Launchpad / bazaar and started copying stuff over from zope.publisher.
[interfaces.]http. I thought that might be a nice way to start things going.

> 
> At our company we've scheduled a project to integrate WebSockets into a
> large Zope3-based application for early next year, so we'll definitely will
> be doing *something* in that space -- we just don't know what, yet. ;)

Same here really. I just thought I'd try and start playing with WebSockets, as 
they sound quite fun, persistent and fast.

> What functionality did you have in mind that the ZTK might grow?

Good question. The main feature I thought ZTK would benefit from, is managing 
the handshake, and forwarding the connection to the relevant socket. I see no 
reason why the server endpoint needs to be a Zope application (could be a 
completely separate application, written in C++ for example), but Zope would 
still need to recognise the URL prefix (ws:// or wss://) and to connect the 
endpoints.

In the grok world, I thought a conf file might be an appropriate way of 
configuring the server socket port numbers and whether to start a listener on 
(or forwarder for) that port. As the initial handshake is done over HTTP, Zope 
would mainly need a way of recognising the WebSocket request and to delegate 
it appropriately.

In terms of public methods for a developer, this would be optional on whether 
Zope / grok manages the endpoint or not. If it did have control of the server-
side WebSocket (e.g. localhost:9999), it would need a write method and methods 
for parsing WebSocket frames for Content-Length etc (see Section 5.2 of 
RFC6455), and to return only the "payload data".

I haven't any experience with bit-wise operations, so could do with some help 
with parsing that first byte of the frame.

Finally, I think testing will be a bit of b*tch, as Zope would also need a 
WebSocket client to perform the testing...

Hope that helps.
Cheers,
Alex



> 
> Wolfgang
-- 
Alex Leach BSc. MRes.
Department of Biology
University of York
York YO10 5DD
United Kingdom
www: http://bioltfws1.york.ac.uk/~albl500
EMAIL DISCLAIMER: http://www.york.ac.uk/docs/disclaimer/email.htm

_______________________________________________
Zope-Dev maillist  -  [email protected]
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )