Re: [Web-SIG] Nodejs cluster
From: est electronix...@gmail.com Thank you guys for all the info. Twisted Web is cool, but there's it's not as interchangeable as WSGI. Twisted Web includes a WSGI container. You can run any WSGI application in it. Jean-Paul ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: https://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Nodejs cluster
From: est electronix...@gmail.com Recently I've been playing with Nodejs and websockets, looks like their community has advanced far ahead of us. For example http://nodejs.org/api/cluster.html The best we've got is something like Celery, or Telegraphy for Django, We The example I gave for Twisted Web on https://stackoverflow.com/questions/10077745/twistedweb-on-multicore- multiprocessor/10088578#10088578 is somewhat similar to this. Jean-Paul ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: https://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] OT: dotted names (Was: Re: A Python Web Application Package and Format)
On 06:22 pm, al...@gothcandy.com wrote: On 2011-04-15 11:02:17 -0700, Jim Fulton said: On Fri, Apr 15, 2011 at 1:32 PM, Éric Araujo mer...@netwok.org wrote: As an aside, I wonder why people use dot+colon notation instead of just dots to reference callables. In distutils2 for example we resolve dotted names to find command classes, command hooks and compilers. So what 19s the benefit, marginally easier parsing? An opportunity of using a colon is that it allows:: dotted.module.name:expression where expression may be more than just a name:: foo.bar:Bar() Or foo.bar:Baz.factory. I wouldn't go so far as to eval() what's after the colon. The real difference is this: [foo.bar]:[Baz.factory] | ^- Attribute lookup. ^- Module lookup. You can't do this: import foo.bar.Baz.factory But you can certainly imagine a function `foo` which accepts foo.bar.Baz.factory and returns the appropriate object. The : doesn't really buy you anything. Jean-Paul ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Server-side async API implementation sketches
On 11:36 am, al...@gothcandy.com wrote: On 2011-01-08 19:34:41 -0800, P.J. Eby said: At 04:40 AM 1/9/2011 +0200, Alex Gr�nholm wrote: 09.01.2011 04:15, Alice Bevan�McGregor kirjoitti: I hope that clearly identifies my idea on the subject. Since asyncservers will /already/ be implementing their own executors, I don'tsee this as too crazy. -1 on this. Those executors are meant for executing code in a threadpool. Mandating a magical socket operation filter here wouldconsiderably complicate server implementation. Actually, the *reverse* is true. If you do it the way Alice proposes, my sketches don't get any more complex, because the filtering goes in the executor facade or submit function. Indeed; the executor is what then adds the file descriptor to the underlying server async reactor (select/epoll/kqueue/other). In the case of the Marrow server, this would utilize a reactor callback (some might say deferred) to Don't say it if it's not true. Deferreds aren't tied to a reactor, and Marrow doesn't appear to have anything called deferred. So this parallel to Twisted's Deferred is misleading and confusing. Since each async server will either implement or utilize a specific async framework, each will offer its own async-supported featureset. What I mean is that all servers should make wsgi.input calls async- able, some would go further to make all socket calls async. Some might go even further than that and define an API for external libraries (e.g. DBs) to be truly cooperatively async. I think this effort would benefit from more thought on how exactly accessing this external library support will work. If async wsgi is limited to performing a single read asynchronously, then it hardly seems compelling. Jean-Paul ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] WSGI and async Servers
On 04:40 pm, armin.ronac...@active-4.com wrote: Hi, For this topic I would love to remember everybody that the web is currently changing and will even more change in the future which will probably also mean that a lot of what we're doing currently might not be common practise in the near future. WSGI is currently not doing to well for asyncronous applications, so people claim. I don't know where this is coming from, probably because everybody still thinks our data storages are traditional databases. But we really have to wake up from that idea and start at least *considering* asynchronous designs when it comes to WSGI. Tornado appeared recently and from a technical perspective, it's a step backwards. It's not supporting all of HTTP and it's clearly not supporting WSGI in any way beyond the very basics. But the interesting point is, that this does not matter for many applications. Even for an application that was never designed to be non-blocking that just recently dropped MySQL for most of the data, Tornado is a huge performance improvement (personal experience). Why would it be good to encourage async applications on top of WSGI? Because people would otherwise come up with their own implementations that are incompatible to each other. Maybe that should not go into WSGI but a AWSGI or whatever, but I'm pretty sure we should at least consider it and ask people that use asynchronous applications/servers what the issues with WSGI are. At PyCon, there was some discussion about what changes could be made to the WSGI spec to extend it to support asynchronous applications. I probably have some notes, and I think I even sent them to the list at the time. Perhaps those with an interest in async WSGI could take a look at those and weigh in on the merits of the conclusions reached. A number of other people also posted to a thread which covered more of the WSGI ideas discussed at PyCon. The top of that thread is here: http://www.mail-archive.com/web-sig@python.org/msg02569.html I posted an example of what an asynchronous WSGI application might look like here: http://www.mail-archive.com/web-sig@python.org/msg02582.html (it looks like I forgot to do anything relating to start_response there - I don't remember if this was intentional or not). I think there was also some talk about how it would be desirable to support asynchronous response header generation. Jean-Paul ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
