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