zope-tests - FAILED: 1, OK: 21
This is the summary for test reports received on the zope-tests list between 2012-11-20 00:00:00 UTC and 2012-11-21 00:00:00 UTC: See the footnotes for test reports of unsuccessful builds. An up-to date view of the builders is also available in our buildbot documentation: http://docs.zope.org/zopetoolkit/process/buildbots.html#the-nightly-builds Reports received ---------------- Successful - zopetoolkit_trunk - Build # 83 Successful - zopetoolkit_trunk_app - Build # 67 Zope-2.10 Python-2.4.6 : Linux Zope-2.11 Python-2.4.6 : Linux Zope-2.12 Python-2.6.8 : Linux Zope-2.13 Python-2.6.8 : Linux Zope-2.13 Python-2.7.3 : Linux Zope-trunk Python-2.6.8 : Linux Zope-trunk Python-2.7.3 : Linux winbot / ZODB_dev py_265_win32 winbot / ZODB_dev py_265_win64 winbot / ZODB_dev py_270_win32 winbot / ZODB_dev py_270_win64 [1] winbot / zc.lockfile_py_265_32 winbot / ztk_10 py_254_win32 winbot / ztk_10 py_265_win32 winbot / ztk_10 py_265_win64 winbot / ztk_11 py_254_win32 winbot / ztk_11 py_265_win32 winbot / ztk_11 py_265_win64 winbot / ztk_11 py_270_win32 winbot / ztk_11 py_270_win64 Non-OK results -------------- [1] FAILED winbot / zc.lockfile_py_265_32 https://mail.zope.org/pipermail/zope-tests/2012-November/069450.html
Hi, I was wondering if anyone has implemented a WebSockets server API using the zope toolkit? I've just submitted a blueprint on Launchpad (https://blueprints.launchpad.net/zopetoolkit-project/+spec/websockets-api), but thought it might be quicker and easier to discuss how one could do this here. In theory (and practice, e.g. http://popdevelop.com/2010/03/a-minimal-python- websocket-server/), only a very small amount of code is needed to deploy a secure WebSockets server. I'd be happy to have a go at doing this myself, but thought it would be better to implement upstream, within one of the zope packages. I've been developing with grok, so I'm not too familiar with the internals of zope publishing, though. Please could someone point me in the right direction, with regards to modules and base classes responsible for parsing requests and performing handshakes? Cheers, Alex
Hi, * Alex Leach <albl500@york.ac.uk> [2012-11-25 20:00]:
I was wondering if anyone has implemented a WebSockets server API using the zope toolkit? I've just submitted a blueprint on Launchpad (https://blueprints.launchpad.net/zopetoolkit-project/+spec/websockets-api), but thought it might be quicker and easier to discuss how one could do this here.
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). Apart from that, I'm not sure what features remain, and where a proper home in the ZTK world would be. 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. ;) What functionality did you have in mind that the ZTK might grow? Wolfgang -- Wolfgang Schnerring · ws@gocept.com · Software development gocept gmbh & co. kg · Forsterstraße 29 · 06112 Halle (Saale) · Germany http://gocept.com · Tel +49 345 219401-0 Python, Pyramid, Plone, Zope · consulting, development, hosting, operations
On 11/27/2012 09:04 AM, Wolfgang Schnerring wrote:
Hi,
* Alex Leach <albl500@york.ac.uk> [2012-11-25 20:00]:
I was wondering if anyone has implemented a WebSockets server API using the zope toolkit? I've just submitted a blueprint on Launchpad (https://blueprints.launchpad.net/zopetoolkit-project/+spec/websockets-api), but thought it might be quicker and easier to discuss how one could do this here.
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).
Apart from that, I'm not sure what features remain, and where a proper home in the ZTK world would be.
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. ;)
What functionality did you have in mind that the ZTK might grow?
Wolfgang
Some investigations and trials showed about half a year ago that a Autobahn + Twisted + pyramid combination worked. YMMV -- Best regards, Adam GROSZER -- Quote of the day: "Nobody can hurt me without my permission." (Mohandas Gandhi)
On Tuesday 27 Nov 2012 10:07:03 Adam GROSZER wrote:
Some investigations and trials showed about half a year ago that a Autobahn + Twisted + pyramid combination worked.
YMMV
Thanks. That is a completely different and separate application stack cf. the standard grok dependencies. I've written quite a lot of Grok-specific code already, and going down that route would seem to add a lot to my list of dependencies... Something which is already getting quite out of hand. Cheers, Alex
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
On Tue, Nov 27, 2012 at 3:04 AM, Wolfgang Schnerring <ws@gocept.com> 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).
Actually, it is. zope.server is based on asyncore. Having said that, my impression is that web sockets is largely (or completely) orthogonal to WSGI and the HTTP-based publishing infrastructure. ZTK is only relevant to the extent that it's a bag of useful libraries maintained by the Zope community. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm
On Tuesday 27 Nov 2012 07:04:43 Jim Fulton wrote:
Actually, it is. zope.server is based on asyncore.
Having said that, my impression is that web sockets is largely (or completely) orthogonal to WSGI and the HTTP-based publishing infrastructure.
From the RFC:
The WebSocket Protocol attempts to address the goals of existing bidirectional HTTP technologies in the context of the existing HTTP infrastructure; as such, it is designed to work over HTTP ports 80 and 443 as well as to support HTTP proxies and intermediaries, even if this implies some complexity specific to the current environment. However, the design does not limit WebSocket to HTTP, and future implementations could use a simpler handshake over a dedicated port without reinventing the entire protocol. This last point is important because the traffic patterns of interactive messaging do not closely match standard HTTP traffic and can induce unusual loads on some components.
ZTK is only relevant to the extent that it's a bag of useful libraries maintained by the Zope community.
It is a bag of useful libraries :) Is there anything that would ease the development of a WebSockets server, though? I would have thought there is, and that it would be at least possible, if not simple, to implement from existing base classes... KR, Alex
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alex Leach wrote:
It is a bag of useful libraries :) Is there anything that would ease the development of a WebSockets server, though? I would have thought there is, and that it would be at least possible, if not simple, to implement from existing base classes...
Use the right tool for each problem. Zope is really not the right choice for implementing a websocket server. There are dozens of better solutions for Python like http://autobahn.ws/ Don't try to misuse a framework for a purpose that it has not been invented for. - -aj -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQGUBAEBAgAGBQJQtOFwAAoJEADcfz7u4AZjsE8Lvii18GvAJm+HKcTYjYJDTglm palnD52tooVrR0QlTomU/x5b72NM9nyCT3zgDuhH3aWmHlckmZ6Q44QFHCh7WwA8 8OhDSQslv7ORFORA7WW9LDf256TcNrQHZCU5XaV9yg+gMgF3+6wdeX0LFBUyjWa6 vcObEnN1YtKvwirog7E9zt2u5hynE8kCuLvcC68aiS+yaqFDLk5hip6e3HZy9GLE DzdGbUqvmrIWseS8F4ExRw3vUX8r3ZNinmQwYASPpHlfzcP/LLgtVAx2eaIkcOS3 EXmLM7FY4Qa1dAx8UXpVIyIWq0RlPmbFkiDdAbtJlrVqOSA/9vgf5rmbVj6xFDBx zlj+8+MoVYiAxohbJQgaG7D5dK7L1N1xLS4szVSCGgJ3RFS+qecYpD8atB1P1s1E AcliGuzDebxLtGjHn8E9r7VDhy+qz7YCLrOKI5Dd6zkU8ukpStYndafo/qXXO5EG HIoAjIQUpLh452h79gf0dG+EpixRzYA= =kRBS -----END PGP SIGNATURE-----
Hi, just sending again to the list... On Tuesday 27 Nov 2012 16:51:13 Andreas Jung wrote:
Use the right tool for each problem. Zope is really not the right choice for implementing a websocket server.
Why is it the wrong tool for the job? I read up a bit on asyncore, and see it's supposedly a single threaded server. Is that part of the problem? The way I see it, zope's got its own web server and framework that handles HTTP requests; WebSockets initially connect over HTTP, before upgrading to a WebSocket connection. If the 'upgrade' request was recognised by zope, then couldn't it just forward the connection on to any WebSocket server? It wouldn't even need to do the handshake, but a compatible proxy would no doubt need to be implemented.
There are dozens of better solutions for Python like
The dependencies of all other Python-based WebSocket implementations all require a completely different application stack. Twisted, which autobahn uses, looks very powerful for low-level networking and the such, but it's a beast and I've never used it before, in favour of making templated web apps with grok.. Also, wouldn't the front-end socket of autobahn conflict with any other running HTTP server? Sure, I could set it up on an alternative port, and use a front-end webserver to proxy requests appropriately, based on URL paths and patterns, like I do now with grok and Apache. But that adds another two complications, when it comes to initially setting up the server. Installation instructions for potential users would become even more off-putting than they already are. The zope server already has a good system for URL parsing and dispatching. Would zope.proxy be any good at proxying WebSocket requests based on the URL?
Don't try to misuse a framework for a purpose that it has not been invented for.
WebSockets hadn't been invented back then, but HTTP was always meant to be bidirectional. Get with the times :b (jk) So, I think I understand that zope might not be great for managing simultaneous bidirectional traffic, which is basically a requirement of a WebSocket server. Could it not be a good proxy either? KR, Alex
participants (6)
-
Adam GROSZER -
Alex Leach -
Andreas Jung -
Jim Fulton -
Wolfgang Schnerring -
Zope tests summarizer