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
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
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.
Alex Leach BSc. MRes.
Department of Biology
University of York
York YO10 5DD
EMAIL DISCLAIMER: http://www.york.ac.uk/docs/disclaimer/email.htm
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -