http://blog.gmane.org/gmane.comp.python.web hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.python.web/4964 <pre>Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP http://sites.google.com/site/worlddump1 organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia richer. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. This fake paper is different from the two fake papers already published (see https://sites.google.com/site/worlddump4 for details) in WORLDCOMP. We MUST say that you should look at the above website if you have any thoughts of participating in WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and threatens the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Prof. Hamid Arabnia makes a lot of tricks. For example, he appeared in a newspaper to fool the public, claiming him a victim of cyber-attack (see Item 8 in Section 5 of above website). Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! We ask Prof. Hamid Arabnia to publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also ask him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 and respond if he has any professional values. Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities at http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. _______________________________________________ Web-SIG mailing list Web-SIG&lt; at &gt;python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org </pre> eliswilson-revL73yDgGBWk0Htik3J/w< at >public.gmane.org 2013-04-30T22:57:23 http://permalink.gmane.org/gmane.comp.python.web/4963 <pre>On Sat, Apr 27, 2013 at 1:24 AM, Graham Dumpleton &lt;graham.dumpleton-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; wrote: Also, wsgi_lite provides a way of registering resources to be closed post-response, that works within WSGI 1.0, also without altering the returned iterable: https://bitbucket.org/pje/wsgi_lite#close-and-resource-cleanups Although wsgi_lite provides programmatic support for this, it's internally implemented as a stock WSGI extension key ('wsgi_lite.closing') in the environ, and can be offered today by servers or middleware in a 1.0 environment. I just haven't gotten around to knocking out a PEP for it. _______________________________________________ Web-SIG mailing list Web-SIG-+ZN9ApsXKcEdnm+yROfE0A&lt; at &gt;public.gmane.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org </pre> PJ Eby 2013-04-27T22:21:31 http://permalink.gmane.org/gmane.comp.python.web/4962 <pre>I described a different way of doing WSGI which would better cope with post response hooks at the Python Web Summit at PyCon in 2012. It made use of the context manager abstraction so it wouldn't screw with the returned iterable. http://www.slideshare.net/GrahamDumpleton/pycon-us-2012-state-of-wsgi-2-14808297 Graham On 27/04/2013, at 2:36 PM, est &lt;electronixtar-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; wrote: _______________________________________________ Web-SIG mailing list Web-SIG-+ZN9ApsXKcEdnm+yROfE0A&lt; at &gt;public.gmane.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org </pre> Graham Dumpleton 2013-04-27T05:24:33 http://permalink.gmane.org/gmane.comp.python.web/4961 <pre>Hi, Newbie opinion here. Since we are talking about Tulip and PEP 3156, I think it's high time we address some of the design flaws in WSGI 1.0 One major problem with WSGI is that it can not handle true post-response hooks. The closest hack I found is this: https://modwsgi.readthedocs.org/en/latest/developer-guides/registering-cleanup-code.html As discussed by Graham Dumpleton here https://groups.google.com/group/modwsgi/msg/d699a09b3b11b313 Although the response was returned to the client, It will still hold the http connection open until __callback finishes. While it's pretty common design pattern for a post-response hook in modern Web world. I can think a few usage: - User uploads file, return HTML says Upload OK, then Web worker continue to transfer file to Amazon S3, which is slow and takes some time. - After a series of user interaction on a web page, using the existing db connection to write OLAP logs of later analysis. - notify the http request to another ZMQ/XMPP connection Currently, Celery is extremely popular (at least in Django or other non-async web frameworks). But IMHO it's too heavy weight and copying python data &amp; objects from a cluster of Web workers to another cluster of task queue workers is not worth it. Another problem is the good old CGI environ design. I can't help to ask? Why? Every HTTP header is transfered via envion, and capitalized with a HTTP_ prefix e.g. HTTP_HOST. There's some serious information loss here. 1. Actual header string case 2. header order Since WSGI is higher level framework, I think it's time for us to deliver the original header status in a SortedDict. Again, as a newbie advice, we should take this chance of integrating PEP 3156 with a deadly simple WSGI 3.0 design: def application(request): ip = request.remote_ip length = request.headers["Content-Length"] request.write("&lt;html&gt;done.&lt;/html&gt;") request.close() db.log(length) # some post-response actions. On Mon, Mar 25, 2013 at 9:08 AM, Guido van Rossum &lt;guido-+ZN9ApsXKcEdnm+yROfE0A&lt; at &gt;public.gmane.org&gt; wrote: _______________________________________________ Web-SIG mailing list Web-SIG-+ZN9ApsXKcEdnm+yROfE0A&lt; at &gt;public.gmane.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org </pre> est 2013-04-27T04:36:29 http://permalink.gmane.org/gmane.comp.python.web/4959 <pre>Il 24/03/2013 06:14, PJ Eby ha scritto: Do you really need a standard async programming API to design and implement an async WSGI specification? I think it is not needed. Some time ago I posted a sample implementation and documentation for a very simple async extension for WSGI: https://bitbucket.org/mperillo/txwsgi An interesting example about how an async API can be designed is PostgreSQL libpq, where the API expose a direct interface to the protocol state machine (pqConsumeInput), so you can not only use it with any async framework you like, but you can also use it in blocking mode. This, as far as I know, is impossible with the network protocol implementations in Twisted or other async frameworks. Regards Manlio _______________________________________________ Web-SIG mailing list Web-SIG-+ZN9ApsXKcEdnm+yROfE0A&lt; at &gt;public.gmane.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org </pre> Manlio Perillo 2013-03-25T21:50:17 http://permalink.gmane.org/gmane.comp.python.web/4953 <pre>On Sat, Mar 23, 2013 at 7:30 PM, Luca Sbardella &lt;luca.sbardella-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; wrote: Because async was added as an afterthought to WSGI about nine years ago, and we didn't get it right, but it long ago was too late to do anything about it. A properly async WSGI implementation will probably have to wait for Tulip (Guido's project to bring a standard async programming API to Python). _______________________________________________ Web-SIG mailing list Web-SIG-+ZN9ApsXKcEdnm+yROfE0A&lt; at &gt;public.gmane.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org </pre> PJ Eby 2013-03-24T05:14:10 http://permalink.gmane.org/gmane.comp.python.web/4952 <pre>[Please follow-up to web-sig, rather than emailing me privately. Thanks.] On Fri, Mar 22, 2013 at 6:52 AM, Simon Yarde &lt;simonyarde-BUHhN+a2lJ4&lt; at &gt;public.gmane.org&gt; wrote: No; middleware isn't even required to pass the same environ object to a nested app. But most middleware will, and won't delete things in it. Raising an exception to be caught would probably be preferable. It might be that the Lite protocol should add a way to convert an exception to a response, e.g. by looking for a __wsgi_response__ attribute on it. That way, you could raise anything you wanted as a default response, and the error would convert to a response at the WSGI 1/Lite boundary. This would mostly be suitable for app-specific errors, but of course you could put error-handling middleware anywhere in the stack below the boundary, or formatting middleware above the boundary. So, thus far, possible extensions to the Lite protocol would be: * Exception to response conversion * A standard for stripping custom HTTP headers I don't have any idea as to when I might get around to these, but if somebody wants to create a model patch or two, that'd be cool. ;-) The protocol of course is looking less and less "lite" with these additions, but I suppose if one looks at "lite" as actually being a collection of "microprotocols" it's not bad at all. Everything in Lite is essentially orthogonal right now (and would continue to be with these additions), so it's nothing like the obscenity of complexity and legacies that is WSGI's core. ;-) _______________________________________________ Web-SIG mailing list Web-SIG-+ZN9ApsXKcEdnm+yROfE0A&lt; at &gt;public.gmane.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org </pre> PJ Eby 2013-03-22T19:02:00 http://permalink.gmane.org/gmane.comp.python.web/4951 <pre> No. You are *allowed* to modify the environment, that's part of the WSGI spec. What you *can't* do is trust that nobody *else* will modify it. Which is why you can't use the environment to communicate with middleware, only objects passed along in the environment. For example, if middleware does env['foobar']=[], it's okay for a called app to modify that list, as long as the middleware saves a reference to it and doesn't try to pull it out of the environ later, e.g.: def middleware(...): my_list = [] env['foobar'] = my_list app(env) if my_list: ....blah But you must NEVER do this: def middleware(...): app(env) if env['foobar']: ....blah Even if you were the one who put 'foobar' into the env. WSGI Lite's argument binding protocol addresses a different problem, which is that after you call app(env), it's too late for you to get anything you need out of the original environment, because app() was within its rights to clear env or change its contents in any way. (It also makes it easier to create application-specific or framework-specific calling conventions, like if you want your controller functions to be called with a user and a cart as parameters, as long as you can define how to get a user and a cart from a WSGI environment.) Yes, you can use that to communicate up the middleware chain, as I showed above. But the problem WSGI Lite bindings solve is not really related to that. Don't do that. You need to put a callback in the environ, or a mutable object that you keep a reference to. The environ dictionary itself is strictly passed down to child handlers, and it's perfectly valid for a piece of middleware to clear the environ entirely before returning to its caller. So you can't use raw values in the environ to communicate up the chain, only down. Of course, even if you use another method to communicate this "final" flag, that doesn't necessarily mean that your "final" flag makes any sense in a WSGI context. It might actually be that you need to use a custom header like 'X-MyFramework-Final', that your boundary middleware strips. That is probably actually the right way to do it in WSGI, because there's no guarantee a "final" response returned from one app is actually going to be the same response as one returned from another piece of middleware wrapping that. So really, since this is information about the response, you should put it in a response header. (Perhaps in a future version of WSGI Lite, I could extend the response protocol to support stripping out some special response headers at the protocol boundary between WSGI 1 and WSGI Lite.) Callbacks and mutable objects are the only way authorized by the WSGI spec to communicate from an app to an outer server or middleware (aside from response headers, bodies, or special response iterators), and WSGI Lite doesn't change this. It just makes it easier to work with values obtained from the environment. _______________________________________________ Web-SIG mailing list Web-SIG-+ZN9ApsXKcEdnm+yROfE0A&lt; at &gt;public.gmane.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org </pre> PJ Eby 2013-03-19T17:47:03 http://permalink.gmane.org/gmane.comp.python.web/4950 <pre>Hi! A quick mail to let you know that we will have a sprint[1] about WebTest[2] at Bearstech, Paris, end of February. Register yourself on the wiki page[2] if you want to join us! You can add your own topic if you need some features. This will be discussed during the sprint. Feel free to ask any questions. Also I can try to help you find a couch/room for your visit if needed. I know that's the event is in a month. And I'm sorry that, for some reasons, I have to announce it that late. Hope you'll be able to come though! Happy hacking! Regards, -- Gael [1] http://bearstech.com/actualites/webtest-paris-sprint [2] http://webtest.readthedocs.org/en/latest/ [3] https://github.com/Pylons/webtest/wiki/ParisSprint2013 _______________________________________________ Web-SIG mailing list Web-SIG-+ZN9ApsXKcEdnm+yROfE0A&lt; at &gt;public.gmane.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org </pre> Gael Pasgrimaud 2013-01-14T11:44:39 http://permalink.gmane.org/gmane.comp.python.web/4949 <pre>From my blog post: http://rpatterson.net/software/wsgi-apps-on-iis The `iiswsgi`_ module implements a FastCGI to `WSGI`_ gateway that is compatible with `IIS`_'s variation of the `FastCGI protocol`_. It also provides `distutils`_ commands for building, distributing and installing `Microsoft Web Deploy`_ (MSDeploy) packages through the `Web Platform Installer`_ (WebPI). The goals of the code in `iiswsgi`_ are to do the following for deploying WSGI apps on IIS: * make it open source as far as possible, right up to IIS * be Pythonic as far as possible, right up to the MSDeploy packaging * re-use our existing tool-chain for distributing packages * share the maintenance burden for a WSGI on Windows story across the community For the `Plone`_ project, it's always been simultaneously a necessity that we support a Windows deployment story and one of our biggest pain points. The Windows installers have always been very different from the other installers. They have had different layouts from our user and developer documentation and even from each other. They have never been maintained or supported by more than one entity, either a company or an individual, and as such have often and ultimately languished. And as for the poor individuals who have tackled the Windows installers, they have almost always burned out and can no longer provide any significant Windows support at all. This is not a healthy open source community dynamic. And yet there is wide consensus that it's not an option *not* to have a Windows deployment story. My hope is that by generalizing the IIS deployment architecture as a `WSGI server`_ and `distutils commands`_, it can be of use to the general Python `WSGI`_ world. I also hope that by doing things 'The Right Way', it will be something that will be clearer and easy to support and maintain. With those two together maybe we can solve the burnout issue by distributing the maintenance load. I'd very much appreciate any help to that end, particularly including feedback on how to get there. I don't care where the code lives and would be happy to see some of it merged back into the packages it derives from or moved into larger packages. So please let me know if you'd like to coordinate moving things around with me. Help Needed ----------- Any contributions are very welcome. Here are a few things I'm looking for in particular: * addressing `Known Issues`_ * IIS app name and Python dist name conventions * fostering community ownership * writing tests I'm particularly apologetic for the last one, I'm ashamed by the lack of tests. In my defense, this whole problem was such a fog for me when I started that I just needed to start writing things and poking around. Believe me this is not my usual MO, I almost always do TDD and beg your forgiveness. :-) I look forward to getting this going! .. _`iiswsgi`: https://github.com/rpatterson/iiswsgi .. _`WSGI`: http://wsgi.readthedocs.org/en/latest/ .. _`IIS`: http://www.iis.net .. _`FastCGI protocol`: http://www.fastcgi.com/drupal/ .. _`distutils`: http://docs.python.org/distutils/ .. _`Microsoft Web Deploy`: http://www.iis.net/downloads/microsoft/web-deploy .. _`Web Platform Installer`: http://www.microsoft.com/web/downloads/platform.aspx .. _`Plone`: http://plone.org .. _`WSGI server`: https://github.com/rpatterson/iiswsgi#iiswsgi-fcgi-gateway .. _`distutils commands`: https://github.com/rpatterson/iiswsgi#build-msdeploy-package .. _`Known Issues`: https://github.com/rpatterson/iiswsgi#known-issues _______________________________________________ Web-SIG mailing list Web-SIG-+ZN9ApsXKcEdnm+yROfE0A&lt; at &gt;public.gmane.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org </pre> Ross Patterson 2012-10-30T18:13:07 http://permalink.gmane.org/gmane.comp.python.web/4948 <pre> [a bunch of useful stuff] Thanks, that was nicely cogent and thus very useful. I've got a first working version: https://github.com/cdent/python3-wsgi-intercept I need to codify some things in tests a bit more, and there's an issue with https request and http.client, but I'm close. </pre> chris.dent-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org 2012-10-02T19:36:26 http://permalink.gmane.org/gmane.comp.python.web/4947 <pre> &gt; * Use bytes or str for environ keys? &gt; * Use bytes or str for environ values? str, decoded from the request bytes using ISO-8859-1. &gt; * Are all environ values created equal or would, for example, &gt; QUERY_STRING's value (prior to any parameter to decoding) &gt; be handled differently from HTTP_COOKIE All environ values are created equal (other than the CGI-mandated odd decoding behaviour of SCRIPT_NAME and PATH_INFO). &gt; * If str, I see that ISO-8859-1 is the assumed encoding. How much &gt; hurt occurs in the world if I just assume utf-8 when decoding to &gt; str[4]? Immediately, all non-ASCII characters in the path would be interpreted incorrectly. The more general hurt to the world would be that we would continue the sad pre-PEP3333 situation where every web server handles non-ASCII characters differently, and so no WSGI application can reliably use Unicode in path segments. There is little impact to any header other than the path, because non-ASCII characters almost never appear in them. The query string remains %-encoded so any non-ASCII characters are safe. The other places users can put non-ASCII characters are in cookies and HTTP Basic Authorisation headers, but browser support here is so variable/broken that Python's handling would be the least of your worries. &gt; [4] Which is what it should have been all along? Not necessarily. Even if you decide that all web apps must use UTF-8 for text encoding, it's valid to have URL-encoded, non-text binary data in a path segment. This would be unrecoverable using straight UTF-8. (They would be recoverable if surrogateescape were used, but PEP 3333 has to encompass language versions that don't have surrogateescape, and also it's questionable whether it should be possible to smuggle non-UTF-8 data into strings that applications assume are safe.) Plus header values are less likely to be UTF-8, and HTTP specifies that they're ISO-8859-1 (even if that is not well-observed by browsers). Ideally, the interfaces should all be bytes, because HTTP is defined in terms of bytes. But that plays poorly with Python 3's default Unicode strs (for environ et al). So ISO-8859-1 was chosen as a str interface for which the original bytes can at least be recovered. &gt; * Should start_response only accept bytes (and error if not), or &gt; should it also accept str and encode appropriately? status and response_headers are, like the request headers, native str (to be ISO-8859-1 encoded). It's only the HTTP entity body that is always bytestring. &gt; * Should the returned iterable be rejected or encoded if not bytes? I don't think it's specified by the PEP, but wsgiref looks like it'll chuck TypeError when it tries to write str to the buffer/socket. cheers, </pre> And Clover 2012-10-02T12:38:27 http://permalink.gmane.org/gmane.comp.python.web/4946 <pre> I was at pyconuk over the weekend and came away from that all refreshed and wanting to hack. That combined with the recent release of Python 3.3 had me deciding it was time to start porting TiddlyWeb[1] to Python3. I'm having progress along some lines and a bit of a mess along others. The major holdback right now are dependencies which are not yet ported, which I'd like to port as well, but proving hard to port because they have test dependencies which themselves are not yet ported. A medium sized issue is related to how WSGI is supposed to behave in Python3. TiddlyWeb is its own framework and doesn't use webob or werkzeug, etc. It does dispatch with selector, but other than that processes handling headers and request body as it gets them from the server. For tests it uses wsgi-intercept[2] to simulate a web server. I've volunteered to port that (having already done some minor work on it in the past) so need to get clear and the disposition of bytes or strings in headers and bodies of both requests and responses. I have a few questions that I'm hoping people here will help me answer, or at least point me in the right direction. I'll be happy to summarize the results after the discussion has tailed off.[3] I've looked over pep 3333 and don't some other reading, but I don't feel fully confident. The question is mostly around what part of the stack should be uptight. In the below when I say "bytes" and "str" I mean the Python 3 types. * Should wsgi-intercept (which fakes a server) when giving request info to a "fake app": * Use bytes or str for environ keys? * Use bytes or str for environ values? * Are all environ values created equal or would, for example, QUERY_STRING's value (prior to any parameter to decoding) be handled differently from HTTP_COOKIE * If str, I see that ISO-8859-1 is the assumed encoding. How much hurt occurs in the world if I just assume utf-8 when decoding to str[4]? * When wsgi-intercept is accepting data from the wsgi app: * Should start_response only accept bytes (and error if not), or should it also accept str and encode appropriately? To put it another way: be liberal or srict? If encoding, which encoding? * Should the returned iterable be rejected or encoded if not bytes? What have I forgotten? Thanks for any input, comments, etc. The thing at [3] has a few more details on some of the related issues and pieces of the puzzle. [1] http://tiddlyweb.com/ https://github.com/tiddlyweb/tiddlyweb [2] http://code.google.com/p/wsgi-intercept/ [3] I've started keeping notes on this project at http://tiddlyweb3.tiddlyspace.com/ [4] Which is what it should have been all along? </pre> chris.dent-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org 2012-10-01T17:07:40 http://permalink.gmane.org/gmane.comp.python.web/4945 <pre> I am using a system that installs each revision of a web application into a new virtualenv in a directory hostname/random-number (uuid), echoes the random number into a file hostname/active and creates a symlink hostname/current -&gt; random-number. A uwsgi config file hosname/config.ini links to the currently active environment by loading its name from the file 'active': [uwsgi] virtualenv = %d/&lt; at &gt;(%d/active) When you touch the .ini file, uwsgi reloads the application. Another file 'history' has all the old 'active' lines in order with timestamps so you can revert. uwsgi's many features allow background workers and so on. _______________________________________________ Web-SIG mailing list Web-SIG-+ZN9ApsXKcEdnm+yROfE0A&lt; at &gt;public.gmane.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org </pre> Daniel Holth 2012-09-12T13:08:32 http://permalink.gmane.org/gmane.comp.python.web/4944 <pre>Hello! Here's a progress update on "sarge", the deployment tool. Turns out I was trying to address too many concerns at once, so I focussed on the core problem: managing the lifecycle of a version of the application. http://mgax.github.com/sarge/ Sarge acts as container for "instances". An instance can be *created*, then you install code and configure stuff; you can then *start* and *stop* it, and when a new version is ready, *destroy* the old one. There's also a *run* command to bring up a REPL or execute custom commands. Some documentation exists: http://mgax.github.com/sarge/ Instances are independent, so you can run them simultaneously; this allows for different instances for different jobs (web, worker, cron script) and also things like rolling back a failed deployment or zero-downtime upgrade. I'm using this, for a couple of projects, in production, today. There's an example fabfile in the repo (deploy/complex_fabfile.py), but it's way more complex than it should be. Much of that logic should probably be handled by sarge itself. Thoughts, ideas? Cheers, </pre> Alex Morega 2012-09-10T16:27:00 http://permalink.gmane.org/gmane.comp.python.web/4943 <pre>Probably better off asking on the Python WEB-SIG. I have cc'd this there. http://www.python.org/community/sigs/current/web-sig/ Someone has probably felt that wsgiref implementation should somehow be checking for things which aren't notionally allowed but which go beyond just API usage checks. Checking for hop by hop headers should possibly have been the job of the wsgiref.validator and not the server in wsgiref. I know of no other server which will outright error when a hop by hop header is returned by an application, and as you note, there are sometimes where it is useful to pass back Connection to ensure that the web server/client drops the current connection and doesn't try and maintain a keep alive connection. Graham On 10 August 2012 02:43, Ron Garret &lt;ron-f4jVjuSzyt5BDgjK7y7TUQ&lt; at &gt;public.gmane.org&gt; wrote: _______________________________________________ Web-SIG mailing list Web-SIG-+ZN9ApsXKcEdnm+yROfE0A&lt; at &gt;public.gmane.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org </pre> Graham Dumpleton 2012-08-10T03:16:24 http://permalink.gmane.org/gmane.comp.python.web/4942 <pre>Gunicorn does upgrade itself using the USR2 signal just like nginx and share the socket like using an fd between OS processes. However the case of a db is a little different since you handle a connection to a db and not listening on a port. You will need either a multiprocess queue passing messages to one process or launching a connection per processes. You can do that using the hook system of gunicorn. - benoît _______________________________________________ Web-SIG mailing list Web-SIG-+ZN9ApsXKcEdnm+yROfE0A&lt; at &gt;public.gmane.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org </pre> Benoit Chesneau 2012-07-15T20:42:53 http://permalink.gmane.org/gmane.comp.python.web/4941 <pre>Le 14/07/2012 06:07, Graham Dumpleton a écrit : I think that est refers to this: http://wiki.nginx.org/CommandLine#Upgrading_To_a_New_Binary_On_The_Fly Apparently yes, there is specific code in nginx to start the new binary and give it the existing socket. And I think that yes, Tarek’s new Circus is similar to the nginx magic upgrade in that an open socket is passed around processes. Maybe nginx even does this in normal operation with multiple worker processes, but I don’t know. Regards, </pre> Simon Sapin 2012-07-15T15:14:35 http://permalink.gmane.org/gmane.comp.python.web/4940 <pre>These uwsgi features are pretty neat! Thank you! I'll try this. On Sat, Jul 14, 2012 at 1:52 PM, Roberto De Ioris &lt;roberto-5KDOxZqKugI&lt; at &gt;public.gmane.org&gt; wrote: _______________________________________________ Web-SIG mailing list Web-SIG-+ZN9ApsXKcEdnm+yROfE0A&lt; at &gt;public.gmane.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org </pre> est 2012-07-14T07:38:15 http://permalink.gmane.org/gmane.comp.python.web/4939 <pre> You can abuse one of the feature you already found in uWSGI. The simplest approach would be using the Spooler (check uWSGI docs). It is a simplified celery, where the queue is a simple 'spool directory' (like a printing system). A non-uWSGI related trick, would be having a thread pool (one for each worker) in which you enqueue tasks from the request handler: http://projects.unbit.it/uwsgi/wiki/Example#threadqueue There are other solutions to your problem, but all are not relevant to WSGI, so you may want to move to discussion to the uWSGI list directly. </pre> Roberto De Ioris 2012-07-14T05:52:46 http://permalink.gmane.org/gmane.comp.python.web/4938 <pre> Unlikely. HTTP connections are stateless, open database connections are high unlikely to be stateless with the client likely caching certain session information. I would be very surprised if you could upgrade nginx, perform a restart and preserve the HTTP listener socket. If you are talking about some other socket I don't know what you are talking about. As you can with Apache, you can likely enact a configuration file change and perform a restart or trigger rereading of the configuration and it would maintain the HTTP listener socket across the configuration restart, but an upgrade implies changing the binary and I know no way that you could easily persist a HTTP listener socket across to an invocation of a new web server instance using a new executable. In Apache you certainly cannot do it, and unless nginx has some magic where the existing nginx execs the new nginx version and somehow communicates through open socket connections to the new process, I very much doubt it would as it would be rather messy to do so. Different WSGI severs would behave differently, especially around process control, but your model of understand is close enough. Would still suggest you just use an existing solution. Graham _______________________________________________ Web-SIG mailing list Web-SIG&lt; at &gt;python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org </pre> Graham Dumpleton 2012-07-14T04:07:01 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.python.web