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