On Saturday 04 February 2006 21:35, Peter Hunt wrote:
> I think CherryPy's WSGI server should go in: it's stable, and the
> best-performing WSGI HTTP server out there.
Are you sure? Is it really scalable? Can you prove it?
Regards,
Stephan
--
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tuft
[Peter Hunt]
> I think CherryPy's WSGI server should go in: it's stable, and the
> best-performing WSGI HTTP server out there.
I disagree.
I think that if a WSGI server is to go into the standard library, it
should be the most basic one possible, e.g. one that builds on the
*HttpServer.py hier
[Guido van Rossum]
> I see. But doesn't this still tie the templates API rather strongly to
> a web API? What if I want to use a template engine to generate
> spam^H^H^H^Hpersonalized emails? Or static HTML pages that are written
> to the filesystem and then served by a classic Apache setup? Or
>I see. But doesn't this still tie the templates API rather strongly to
>a web API? What if I want to use a template engine to generate
>spam^H^H^H^Hpersonalized emails?
Then set the content-type to message/rfc822. ;)
> Or static HTML pages that are written
>to the filesystem and then served
> [Peter Hunt]
> > I think CherryPy's WSGI server should go in: it's stable, and the
> > best-performing WSGI HTTP server out there.
[Alan Kennedy]
> I disagree.
>
> I think that if a WSGI server is to go into the standard library, it
> should be the most basic one possible, e.g. one that builds o
At 01:28 PM 2/5/2006 +, Alan Kennedy wrote:
>I've been dismayed over the last few days trying to follow the direction
>of this thread: it appears to me that something very simple has now
>become very complex.
On the contrary, the situation is and always has been very complex. It
only appears
[Me]
> > Or static HTML pages that are written
> >to the filesystem and then served by a classic Apache setup? Or source
> >code (program generators are fun toys!)?
[Phillip]
> Use the output file's write() method as the "write" callback returned by
> start_response(), or use one of the wsgiref h
At 10:40 AM 2/5/2006 -0800, Guido van Rossum wrote:
>[Me]
> > > Or static HTML pages that are written
> > >to the filesystem and then served by a classic Apache setup? Or source
> > >code (program generators are fun toys!)?
>
>[Phillip]
> > Use the output file's write() method as the "write" callb
On Feb 5, 2006, at 10:40 AM, Guido van Rossum wrote:
> I didn't see an output file in the proposed standard. All I saw was a
> WSGI interface. The output file is a figment of your implementation.
The WSGI interface indicates that the WSGI app will return its output
as an iterable. While WSGI wa
[Phillip J. Eby]
> Developing WSGI was not easy, either, as I'm sure you recall.You and I
> certainly argued a bit about iterators and file-like objects and such,
> and it took a while before I understood all of your use cases and we
> were able to resolve them in the spec. If you had given up
> # Or use Kid:
> kidengine = KidTemplate(**kid_args)
> content, headers = kidengine('some.template.kid', wsgi=False)
>
> # web
> return kidengine(environ, start_response)
>
> Or if people don't like relying on the object to determine if there's
> a keyword with wsgi = False,
>
> content, headers =
Phillip J. Eby wrote:
>>This topic started with Buffet, the de-facto standard templating API for
>>CherryPy. Buffet is just about textual templating, which is a good
>>thing. That's why it's very simple, and is thus actually being used.
>
>
> Which is precisely why we don't need to rush into bles
Ian Bicking wrote:
> def render(template_instance, vars, format="html", fragment=False):
Here I can magically turn this into a WEB templating spec:
def render(template_instance, vars, format="html", fragment=False,
wsgi_environ=None, set_header_callback=None)
wsgi_environ is the environ d
Phillip J. Eby wrote:
>>It is my strong preference that the standard API we are attempting to
>>design here does *not* tie you strongly to WSGI or the generation of
>>dynamic web content.
>
>
> That seems to be a popular position, to be sure. However, since there is
> already a de facto standar
Ben Bangert wrote:
>># Or use Kid:
>>kidengine = KidTemplate(**kid_args)
>>content, headers = kidengine('some.template.kid', wsgi=False)
>>
>># web
>>return kidengine(environ, start_response)
>>
>>Or if people don't like relying on the object to determine if there's
>>a keyword with wsgi = False,
>
At 02:46 PM 2/5/2006 -0600, Ian Bicking wrote:
>Ian Bicking wrote:
> > def render(template_instance, vars, format="html", fragment=False):
>
>Here I can magically turn this into a WEB templating spec:
>
>def render(template_instance, vars, format="html", fragment=False,
>wsgi_environ=None, se
At 03:26 PM 2/5/2006 -0600, Ian Bicking wrote:
>Even the most trivial of web applications needs templates to include
>other templates, so the fact that this doesn't do anything to aid or
>specify that makes the spec feel leaky. I can indicate where the
>template comes from initially, but all bets
At 02:36 PM 2/5/2006 -0600, Ian Bicking wrote:
>I think very minor fixes could improve it -- for instance, allow
>template_filename as an argument instead of only template_name. Then at
>least simple template filling would be handled well (e.g., enough for
>Paste Script), though it is unlikely
Phillip J. Eby wrote:
> At 02:46 PM 2/5/2006 -0600, Ian Bicking wrote:
>
>> Ian Bicking wrote:
>> > def render(template_instance, vars, format="html",
>> fragment=False):
>>
>> Here I can magically turn this into a WEB templating spec:
>>
>> def render(template_instance, vars, format="html"
Ian Bicking wrote:
> Ian Bicking wrote:
>
>> def render(template_instance, vars, format="html", fragment=False):
>
>
> Here I can magically turn this into a WEB templating spec:
>
> def render(template_instance, vars, format="html", fragment=False,
> wsgi_environ=None, set_header_callbac
Phillip J. Eby wrote:
> At 03:26 PM 2/5/2006 -0600, Ian Bicking wrote:
>
>> Even the most trivial of web applications needs templates to include
>> other templates, so the fact that this doesn't do anything to aid or
>> specify that makes the spec feel leaky. I can indicate where the
>> template
On Feb 5, 2006, at 6:17 PM, Ian Bicking wrote:
> ``set_header_callback`` is a function that can be called
> like
> ``set_header_callback(header_name, header_value)``.
> Arguments can only be strings (not unicode) [encode unicode
> with ASCII?]. The header
James Y Knight wrote:
> On Feb 5, 2006, at 6:17 PM, Ian Bicking wrote:
>
>> ``set_header_callback`` is a function that can be called like
>> ``set_header_callback(header_name, header_value)``.
>> Arguments can only be strings (not unicode) [encode unicode
>>
On 2/5/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> I suspect most templates will buffer their output internally, unless
> somehow configured or dynamically set not to do so.
Why would they? Isn't that a function that the web server typically does?
--
--Guido van Rossum (home page: http://www.pyt
On 2/5/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> * There was an ad hoc standardization happening with TG and Buffet.
>
> * Other people were becoming interested.
>
> * Discussion was happening on the TG list, where most people on the TG
> list were not particularly interested about this sort of
On Feb 5, 2006, at 5:33 PM, Phillip J. Eby wrote:
> As Ben has previously pointed out, systems like Myghty are going to
> ignore
> your 'find_template()' because they do their own finding. So the
> spec will
> leak no matter what, until we get to the level of specification
> called for
> b
Michael Bayer wrote:
> Im not totally following every detail of this discussionbut correct
> me if I'm wrong, if we are just talking about a specification of how
> the various components of a template engine are to look and interact
> with each other, there is no reason Myghty's resolver
27 matches
Mail list logo
