From ggbaker at sfu.ca  Sat Mar 13 02:19:25 2004
From: ggbaker at sfu.ca (ggbaker@sfu.ca)
Date: Sat Mar 13 02:19:30 2004
Subject: [Web-SIG] safe pickle?
Message-ID: <20040313071923.GB4906@lefty.cs.sfu.ca>

Is there a version of pickle that can be sfaely used with non-trusted 
data?  It would be very nice to be able to do something like this in a 
CGI script:

    print '<input type="hidden" name="state" value="' + \
            cgi.escape( safepickle(stateinfo) ,True) + '" />'

    # in next script
    stateinfo = safeunpickle(form["state"].value)

Of course, the actual contents of the stateinfo variable would be 
untrusted at this point, but that's always there with submitted data.

The pickle.load function is advertized as unsafe with untrusted data.  
Is there anything similar that is safe?  Obviously, it would have to be 
more restricted than pickle.

Greg Baker, Lecturer
School of Computing Science
Simon Fraser University
Burnaby, BC, V5A 1S6
E-mail: ggbaker@cs.sfu.ca

From wilk-ml at flibuste.net  Sat Mar 13 05:24:55 2004
From: wilk-ml at flibuste.net (William Dode)
Date: Sat Mar 13 05:25:01 2004
Subject: [Web-SIG] safe pickle?
In-Reply-To: <20040313071923.GB4906@lefty.cs.sfu.ca> (ggbaker@sfu.ca's
	message of "Fri, 12 Mar 2004 23:19:25 -0800")
References: <20040313071923.GB4906@lefty.cs.sfu.ca>
Message-ID: <87llm511u0.fsf@blakie.riol>

ggbaker@sfu.ca writes:

> Is there a version of pickle that can be sfaely used with non-trusted 
> data?  It would be very nice to be able to do something like this in a 
> CGI script:
>
>     print '<input type="hidden" name="state" value="' + \
>             cgi.escape( safepickle(stateinfo) ,True) + '" />'
>
>     # in next script
>     stateinfo = safeunpickle(form["state"].value)
>
> Of course, the actual contents of the stateinfo variable would be 
> untrusted at this point, but that's always there with submitted data.
>
> The pickle.load function is advertized as unsafe with untrusted data.  
> Is there anything similar that is safe?  Obviously, it would have to be 
> more restricted than pickle.

I think you should use a sessionID and pickle inside the server... Even
if pickle was safe you could always have problem with incoherent data.

You can also look at yaml to pickle data in a safer way.

bye

-- 
William - http://flibuste.net

From ianb at colorstudy.com  Sat Mar 13 15:16:22 2004
From: ianb at colorstudy.com (Ian Bicking)
Date: Sat Mar 13 15:17:20 2004
Subject: [Web-SIG] safe pickle?
In-Reply-To: <20040313071923.GB4906@lefty.cs.sfu.ca>
References: <20040313071923.GB4906@lefty.cs.sfu.ca>
Message-ID: <4BEEE1B3-752B-11D8-9B3B-000393C2D67E@colorstudy.com>

On Mar 13, 2004, at 1:19 AM, ggbaker@sfu.ca wrote:
> Is there a version of pickle that can be sfaely used with non-trusted
> data?  It would be very nice to be able to do something like this in a
> CGI script:
>
>     print '<input type="hidden" name="state" value="' + \
>             cgi.escape( safepickle(stateinfo) ,True) + '" />'
>
>     # in next script
>     stateinfo = safeunpickle(form["state"].value)
>
> Of course, the actual contents of the stateinfo variable would be
> untrusted at this point, but that's always there with submitted data.

You need to sign your pickle.  Briefly, you have a server-side secret 
(a string); you concatenate that secret string with the pickle string, 
and make a hash of that (using md5 or sha1), and put that in a second 
hidden field.  When you get the hidden pickle field back, you 
reconstruct that hash and check it against the hash you received -- if 
it matches, then you know it's the same pickle you gave them.

--
Ian Bicking | ianb@colorstudy.com | http://blog.ianbicking.org


From ngps at netmemetic.com  Sat Mar 13 21:00:04 2004
From: ngps at netmemetic.com (Ng Pheng Siong)
Date: Sat Mar 13 21:01:39 2004
Subject: [Web-SIG] safe pickle?
In-Reply-To: <4BEEE1B3-752B-11D8-9B3B-000393C2D67E@colorstudy.com>
References: <20040313071923.GB4906@lefty.cs.sfu.ca>
	<4BEEE1B3-752B-11D8-9B3B-000393C2D67E@colorstudy.com>
Message-ID: <20040314020004.GA484@vista.netmemetic.com>

On Sat, Mar 13, 2004 at 02:16:22PM -0600, Ian Bicking wrote:
> >Of course, the actual contents of the stateinfo variable would be
> >untrusted at this point, but that's always there with submitted data.
> 
> You need to sign your pickle.  Briefly, you have a server-side secret 
> (a string); you concatenate that secret string with the pickle string, 
> and make a hash of that (using md5 or sha1), and put that in a second 
> hidden field.  When you get the hidden pickle field back, you 
> reconstruct that hash and check it against the hash you received -- if 
> it matches, then you know it's the same pickle you gave them.

OP may also wish to add an expiry timestamp into the mix, to prevent
replay attacks. This may be in the pickled data or added with the hashing
key.

See AuthCookies in M2Crypto (url in .sig) for an implementation.


-- 
Ng Pheng Siong <ngps@netmemetic.com> 

http://firewall.rulemaker.net -+- Firewall Change Management & Version Control
http://sandbox.rulemaker.net/ngps -+- Open Source Python Crypto & SSL

From insom at iol.ie  Wed Mar 17 05:58:42 2004
From: insom at iol.ie (Aaron Brady)
Date: Wed Mar 17 05:58:54 2004
Subject: [Web-SIG] Shameless self promotion, and serious question.
Message-ID: <Pine.WNT.4.58.0403171056260.2972@slut>

http://insom.me.uk/blog/Tech/Python/templating.writeback

Rather than come up with YAPWF (Python Web Framework), what would be
people's thoughts on stripping down Quixote to it's bare minimum (I'm
thinking, removing PTL and letting people use what they want;
TAL/Cheetah/"".join()) and that being a contender for the standard
library?

The code base is a joy to work with, so I'd have no problem doing it, if
it sounds like a reasonable idea? (In fairness, there's not a lot of
baggage to strip out!).

Aaron

-- 
"Lack of planning on your part, does not constitute an
emergency on my part."
 -- Office Wisdom (stolen from NooneCasey.ie)

From amk at amk.ca  Wed Mar 17 06:59:07 2004
From: amk at amk.ca (A.M. Kuchling)
Date: Wed Mar 17 07:02:05 2004
Subject: [Web-SIG] Shameless self promotion, and serious question.
In-Reply-To: <Pine.WNT.4.58.0403171056260.2972@slut>
References: <Pine.WNT.4.58.0403171056260.2972@slut>
Message-ID: <20040317115906.GA17728@rogue.amk.ca>

On Wed, Mar 17, 2004 at 10:58:42AM +0000, Aaron Brady wrote:
> Rather than come up with YAPWF (Python Web Framework), what would be
> people's thoughts on stripping down Quixote to it's bare minimum (I'm
> thinking, removing PTL and letting people use what they want;

Note that PTL is already optional; simply never import and call
enable_ptl(), and the PTL import hook is never installed.  As you've
discovered, it's not too difficult to use alternative templating schemes;
you've used Cheetah, and I wrote up a recipe for using ZPT
(http://www.quixote.ca/qx/TemplatingWithZpt).  The ptl_compile and
ptl_import modules only add up to around 500 lines, so it wouldn't reduce
the code size of Quixote very much.

--amk

From titus at caltech.edu  Wed Mar 17 11:47:22 2004
From: titus at caltech.edu (Titus Brown)
Date: Wed Mar 17 11:47:30 2004
Subject: [Web-SIG] Shameless self promotion, and serious question.
In-Reply-To: <Pine.WNT.4.58.0403171056260.2972@slut>
References: <Pine.WNT.4.58.0403171056260.2972@slut>
Message-ID: <20040317164722.GK25375@caltech.edu>

-> http://insom.me.uk/blog/Tech/Python/templating.writeback
-> 
-> Rather than come up with YAPWF (Python Web Framework), what would be
-> people's thoughts on stripping down Quixote to it's bare minimum (I'm
-> thinking, removing PTL and letting people use what they want;
-> TAL/Cheetah/"".join()) and that being a contender for the standard
-> library?
-> 
-> The code base is a joy to work with, so I'd have no problem doing it, if
-> it sounds like a reasonable idea? (In fairness, there's not a lot of
-> baggage to strip out!).

I like and use Quixote, so of course I'm in favor.

But I don't see any particular reason to push it into the standard
library over e.g. Webware, which the group I work in uses and also
likes.

These two frameworks support very different programming styles,
some of which may be better suited for some jobs, and some people, than
others.

I'd be more interested in seeing a standardized connection system (e.g.
SCGI) than anything else.  Where to draw the line is a tough question,
but I think the http_request and http_response aspects of Quixote
(originally taken from Zope, ne c'est pas?) are quite useful and
could be made universal.

cheers,
--titus

From ianb at colorstudy.com  Wed Mar 17 11:58:44 2004
From: ianb at colorstudy.com (Ian Bicking)
Date: Wed Mar 17 12:02:15 2004
Subject: [Web-SIG] Shameless self promotion, and serious question.
In-Reply-To: <Pine.WNT.4.58.0403171056260.2972@slut>
References: <Pine.WNT.4.58.0403171056260.2972@slut>
Message-ID: <405883C4.9040700@colorstudy.com>

Aaron Brady wrote:
> Rather than come up with YAPWF (Python Web Framework), what would be
> people's thoughts on stripping down Quixote to it's bare minimum (I'm
> thinking, removing PTL and letting people use what they want;
> TAL/Cheetah/"".join()) and that being a contender for the standard
> library?

What would the goal be in this? (I ask non-rhetorically)

Or, coming from the other direction (from tabula rasa, instead of from 
quixote), what would you specifically bring in from quixote?

I'd still love to see a standard request and response -- any request and 
response, as long as it isn't too terribly annoying (like FieldStorage).

Besides the request and response, I suppose there is the publisher.  I'm 
less certain of its general applicability.

   Ian

From paul.boddie at ementor.no  Wed Mar 17 12:15:38 2004
From: paul.boddie at ementor.no (Paul Boddie)
Date: Wed Mar 17 12:15:45 2004
Subject: [Web-SIG] Shameless self promotion, and serious question.
Message-ID: <FD72AF7813F1294C95279EC6D9784A2F4B81A3@100NOOSLMSG004.common.alpharoot.net>

> I'd still love to see a standard request and response -- any request and
> response, as long as it isn't too terribly annoying (like FieldStorage).
> Besides the request and response, I suppose there is the publisher.  I'm
> less certain of its general applicability.

More self-promotion, but what do you think of the WebStack stuff I announced
on PyPI?

http://www.python.org/pypi?:action=display&name=WebStack&version=0.2

There's a single transaction class which manages access to request and
response information - it's done that way because some frameworks make
little distinction between requests and responses, or at least not enough to
justify two distinct classes. I've found some aspects of current framework
support to be rather irritating - FieldStorage is just one part of that -
and sometimes one wonders if it's really possible to make a sane layer of
functionality without undoing the dubious design decisions of various
frameworks and then having to reimplement that sanity, afresh, on top.

Paul

From insom at iol.ie  Wed Mar 17 14:16:14 2004
From: insom at iol.ie (Aaron Brady)
Date: Wed Mar 17 14:16:26 2004
Subject: [Web-SIG] Shameless self promotion, and serious question.
In-Reply-To: <405883C4.9040700@colorstudy.com>
References: <Pine.WNT.4.58.0403171056260.2972@slut>
	<405883C4.9040700@colorstudy.com>
Message-ID: <Pine.WNT.4.58.0403171912040.2972@slut>

IB> What would the goal be in this? (I ask non-rhetorically)
IB>
IB> Or, coming from the other direction (from tabula rasa, instead of from
IB> quixote), what would you specifically bring in from quixote?
IB>
IB> I'd still love to see a standard request and response -- any request and
IB> response, as long as it isn't too terribly annoying (like FieldStorage).
IB>
IB> Besides the request and response, I suppose there is the publisher.  I'm
IB> less certain of its general applicability.

Well I was thinking about request, response and publisher, though now that
I think about it, publisher is not as general as I thought.

Quixote's req/res are based off of Zope, albeit a version from the distant
past, and I've found them to be pretty comprehensive. They could be
reasonable easily layered on top of CGI too.

Aaron

From ianb at colorstudy.com  Wed Mar 17 14:23:42 2004
From: ianb at colorstudy.com (Ian Bicking)
Date: Wed Mar 17 14:26:51 2004
Subject: [Web-SIG] Shameless self promotion, and serious question.
In-Reply-To: <Pine.WNT.4.58.0403171912040.2972@slut>
References: <Pine.WNT.4.58.0403171056260.2972@slut>	<405883C4.9040700@colorstudy.com>
	<Pine.WNT.4.58.0403171912040.2972@slut>
Message-ID: <4058A5BE.6030403@colorstudy.com>

Aaron Brady wrote:
> Quixote's req/res are based off of Zope, albeit a version from the distant
> past, and I've found them to be pretty comprehensive. They could be
> reasonable easily layered on top of CGI too.

It's been a while since I looked at them, but I do remember having a 
concern that the response didn't seem to support streaming.  I.e., you 
couldn't write to the response and have that immediately sent to the 
client.  Most of the time you don't need or want this, but for serving 
large files it is important.

Otherwise those request and response objects looked fine to me as far as 
I remember.

   Ian

From mailinglists at qinternet.com  Wed Mar 17 14:30:58 2004
From: mailinglists at qinternet.com (Brian Olsen (Mailing Lists))
Date: Wed Mar 17 14:31:02 2004
Subject: [Web-SIG] Shameless self promotion, and serious question.
In-Reply-To: <405883C4.9040700@colorstudy.com>
References: <Pine.WNT.4.58.0403171056260.2972@slut>
	<405883C4.9040700@colorstudy.com>
Message-ID: <1079551858.1134.6.camel@junk.nycinternet.org>


> I'd still love to see a standard request and response -- any request and 
> response, as long as it isn't too terribly annoying (like FieldStorage).

After reading this thread, I have come to retract, sort of, the opinion
I held before against *too much* standardization.

A Request and Response class is okay. Something like that can be easily
merged together to make it feel like one class. The init parameters
should be pretty common: a CGI dictionary for example. The two classes
shouldn't imply too much about the environment it is being used in.

What I think will also be useful would be a standard set of functions
for escaping characters, packaged in one place.

I think that would be a good start. Though, I can't think of anything
else to add to the list.

Brian


From ianb at colorstudy.com  Wed Mar 17 14:54:43 2004
From: ianb at colorstudy.com (Ian Bicking)
Date: Wed Mar 17 14:57:50 2004
Subject: [Web-SIG] Shameless self promotion, and serious question.
In-Reply-To: <FD72AF7813F1294C95279EC6D9784A2F4B81A3@100NOOSLMSG004.common.alpharoot.net>
References: <FD72AF7813F1294C95279EC6D9784A2F4B81A3@100NOOSLMSG004.common.alpharoot.net>
Message-ID: <4058AD03.7080100@colorstudy.com>

Paul Boddie wrote:
> More self-promotion, but what do you think of the WebStack stuff I announced
> on PyPI?

It kind of opens all sorts of questions.  For instance, it's not 
unreasonable that Webware could run under mod_python or Twisted (I think 
a mod_python version existed a long time ago, and I experimented with 
running it under Twisted a while ago as well).  (And Quixote already 
does this in a less experimental fashion)

So, Quixote, or a more developed Webware, or a bunch of other 
frameworks, could each be a kind of compatibility layer of their own. 
Well, they *could*, but I don't think it's that easy.  But why not?  I'm 
not up to figuring out quite why right now -- but I think it has to do 
with fuzzy layers.

It seems natural that a framework could support one of several 
underlying layers (e.g., Apache and Twisted).  But the layers aren't 
very firm (what's "underlying"?).  Can Quixote work under Webware and 
vice versa?  Or something heavier, like Zope?  And what does "work" 
mean, anyway?  Perhaps that a URL space is segmented off, delegated to a 
subframework.  Or by extension, ala Apache?  What about the frameworks 
intermediate work getting to that subspace, like if Zope authenticated a 
person at a higher level in the URL?

I don't know... I don't think it's necessarily *that* hard.  But we have 
to think recursively somewhere in here, instead of layers -- we can only 
build on lower-level layers for a while, at some point peers have to 
work together in a friendly way.  In this case that would mean running 
Webware ontop of WebStack ontop of Twisted, or seemingly silly things 
like that.  But it's not really that silly, because I suspect it would 
be fairly useful.

But I'm not exactly sure how reasonable it is -- maybe it would be 
better to decouple frameworks and separate layers so that this doesn't 
all have to be so vague, and so we can feel more confident in how things 
will work together.

   Ian

From amk at amk.ca  Wed Mar 17 16:03:31 2004
From: amk at amk.ca (A.M. Kuchling)
Date: Wed Mar 17 16:06:29 2004
Subject: [Web-SIG] Shameless self promotion, and serious question.
In-Reply-To: <FD72AF7813F1294C95279EC6D9784A2F4B81A3@100NOOSLMSG004.common.alpharoot.net>
References: <FD72AF7813F1294C95279EC6D9784A2F4B81A3@100NOOSLMSG004.common.alpharoot.net>
Message-ID: <20040317210331.GA19122@rogue.amk.ca>

On Wed, Mar 17, 2004 at 06:15:38PM +0100, Paul Boddie wrote:
> support to be rather irritating - FieldStorage is just one part of that -
> and sometimes one wonders if it's really possible to make a sane layer of
> functionality without undoing the dubious design decisions of various
> frameworks and then having to reimplement that sanity, afresh, on top.

I suspect that most web frameworks will bypass the 'cgi' module as much as
possible; it's too messy to deal with and too difficult to clean up.

I'm puzzled by the WebStack package.  Why implement a layer of sanity on top
of various dubious frameworks, instead of just implementing that layer of
sanity directly?  But then it's just another framework, and it becomes
apparent that definitions of sanity differ.

--amk

From paul.boddie at ementor.no  Thu Mar 18 05:39:48 2004
From: paul.boddie at ementor.no (Paul Boddie)
Date: Thu Mar 18 05:39:54 2004
Subject: [Web-SIG] Shameless self promotion, and serious question.
Message-ID: <FD72AF7813F1294C95279EC6D9784A2F4B81A5@100NOOSLMSG004.common.alpharoot.net>

A.M. Kuchling [mailto:amk@amk.ca] wrote:
> 
> On Wed, Mar 17, 2004 at 06:15:38PM +0100, Paul Boddie wrote:
> > support to be rather irritating - FieldStorage is just one part of that -
> > and sometimes one wonders if it's really possible to make a sane layer of
> > functionality without undoing the dubious design decisions of various
> > frameworks and then having to reimplement that sanity, afresh, on top.
> 
> I suspect that most web frameworks will bypass the 'cgi' module as much as
> possible; it's too messy to deal with and too difficult to clean up.

Yes, I doubt that most people actually use the FieldStorage class to the
extent of its design; that is, the way that objects of that class can
presumably reside in hierarchies, given the MIME-based nature of HTTP
message bodies. On that front, it's important to distinguish between
"fields" which come from the URL and those which come from some part of the
message body; there have been various discussions about "merging GET and
POST parameters", but the different frameworks are pretty inconsistent on
this. Another disturbing aspect of FieldStorage is the usage of temporary
files and other seemingly "early Web Age" techniques.

> I'm puzzled by the WebStack package.  Why implement a layer of sanity on top
> of various dubious frameworks, instead of just implementing that layer of
> sanity directly?  But then it's just another framework, and it becomes
> apparent that definitions of sanity differ.

Well, when peeling back framework behaviour which seems errant, and
attempting to support BaseHTTPRequestHandler as a first-class framework, one
does almost start to implement one's own "sane" framework. Anyway, my
motivations should be clearly stated in the README.txt file, but my belief
was that most frameworks do most things in mostly the right way, and by
making use of those mechanisms and exposing them to applications in a
unified fashion, one doesn't have to care about which framework one is going
to be deploying on. Some people are wedded to the choice of certain
frameworks, either for practical or for ideological reasons, but that
doesn't mean that the applications available have to be divided up into
"exclusive", fragmented groups which then have to be ported between
frameworks as the need arises.

A side effect of this, given various oversights in various frameworks, is
that a library of knowledge and techniques can be built up both around each
framework and around the implementation of Web/HTTP mechanisms in general.
It's a bit like a code version of the Web Frameworks Overview but with stuff
you can play with. But really, I just want to be able to deploy things on
different frameworks, hopefully providing things like better URL-to-resource
mapping within applications - an area which often seems incoherent or just
poorly supported within today's frameworks. Whether it's possible to work
around every limitation at a higher level than the underlying framework
seems doubtful, but it's arguably better than slowly drifting towards an
agreement over a vague API specification that none of the framework
developers are interested in implementing anyway.

Paul

From paul.boddie at ementor.no  Thu Mar 18 05:56:06 2004
From: paul.boddie at ementor.no (Paul Boddie)
Date: Thu Mar 18 05:56:11 2004
Subject: [Web-SIG] Shameless self promotion, and serious question.
Message-ID: <FD72AF7813F1294C95279EC6D9784A2F4B81A6@100NOOSLMSG004.common.alpharoot.net>

Ian Bicking [mailto:ianb@colorstudy.com] wrote:
> 
> Paul Boddie wrote:
> > More self-promotion, but what do you think of the WebStack stuff I
> > announced on PyPI?
> 
> It kind of opens all sorts of questions.  For instance, it's not 
> unreasonable that Webware could run under mod_python or Twisted (I think
> a mod_python version existed a long time ago, and I experimented with 
> running it under Twisted a while ago as well).  (And Quixote already 
> does this in a less experimental fashion)

To me, running Webware on top of another framework seems only to have
deployment benefits, although one could easily say the same about WebStack.
However, Webware also ties the developer to a way of working which carries a
lot of semantic baggage - the servlet model, threading, and so on.

> So, Quixote, or a more developed Webware, or a bunch of other 
> frameworks, could each be a kind of compatibility layer of their own. 
> Well, they *could*, but I don't think it's that easy.  But why not?  I'm
> not up to figuring out quite why right now -- but I think it has to do 
> with fuzzy layers.

Yes, one could argue that hiding the special parts of frameworks or
correcting the behaviour of such frameworks is the wrong solution to
whichever problem one is trying to solve.

> It seems natural that a framework could support one of several 
> underlying layers (e.g., Apache and Twisted).  But the layers aren't 
> very firm (what's "underlying"?).  Can Quixote work under Webware and 
> vice versa?  Or something heavier, like Zope?  And what does "work" 
> mean, anyway?  Perhaps that a URL space is segmented off, delegated to a
> subframework.  Or by extension, ala Apache?  What about the frameworks 
> intermediate work getting to that subspace, like if Zope authenticated a
> person at a higher level in the URL?

Actually, the issue here seems to be how deep your frameworks are. Most
Python frameworks seem to aspire to "deepness", covering everything from
socket communication right up to session management and application
semantics. What I'd rather see is a collection of layered frameworks and
components which each do their bit of the job. WebStack mostly sits above
the communications layer, using the existing frameworks for that layer and
reusing other parts of those frameworks for higher level features that
should arguably exist elsewhere.

Above WebStack should be components which interpret URLs, control access to
resources, and provide the application-level services. A counterexample of
such an architecture is "Zope plus Products": by the time a Product instance
gets hold of request information, a lot of the decisions about where that
Product instance resides in the URL space have already been taken, but
that's arguably the whole nature of Zope and the way it works and is just
one reason why some people don't really get on with Zope.

> I don't know... I don't think it's necessarily *that* hard.  But we have
> to think recursively somewhere in here, instead of layers -- we can only
> build on lower-level layers for a while, at some point peers have to 
> work together in a friendly way.  In this case that would mean running 
> Webware ontop of WebStack ontop of Twisted, or seemingly silly things 
> like that.  But it's not really that silly, because I suspect it would 
> be fairly useful.

I'm not advocating a Web frameworks equivalent to User Mode Linux. ;-)

> But I'm not exactly sure how reasonable it is -- maybe it would be 
> better to decouple frameworks and separate layers so that this doesn't 
> all have to be so vague, and so we can feel more confident in how things
> will work together.

I'd certainly advocate such an approach instead, however.

Paul

From lucid at escex.com  Fri Mar 19 11:57:40 2004
From: lucid at escex.com (Lucid Drake)
Date: Fri Mar 19 11:55:29 2004
Subject: [Web-SIG] Shameless self promotion, and serious question.
In-Reply-To: <FD72AF7813F1294C95279EC6D9784A2F4B81A6@100NOOSLMSG004.common.alpharoot.net>
References: <FD72AF7813F1294C95279EC6D9784A2F4B81A6@100NOOSLMSG004.common.alpharoot.net>
Message-ID: <88740DF1-79C6-11D8-AEC9-000A95C48278@escex.com>

Less talk, more action.

At the risk of putting myself out there as all talk and no action, I 
think it would be useful for those on this list that have a strong idea 
about what should be added to the Python standard library, to post 
something that people can play around with.

I am by no means an expert in the world of web programming, but I am 
learning, and I do feel the need to have a better set of standard tools 
in Python for developing web applications. I just don't have the 
knowledge or expertise to develop something myself.

But what I've noticed is that there are spurts of activity on this 
list, but no progress. Perhaps if someone actually coded something and 
allowed others to play with it, some progress would be made.

I recall hearing the argument that whatever is developed shouldn't 
break current frameworks, or force them into a model they don't want to 
use. My question is, why would a new module break or force anything? 
Won't the original modules still exist?

In addition, even if the new proposed way of doing things breaks a 
framework, how long would it REALLY take for the framework to 
accommodate the changes?

All this talk is going no where, what ever happened to experimentation? 
Create something, test it, use it, stress it, and learn by doing. Less 
abstract design and more progress through action please.

Am I right? Wrong? Not seeing the entire picture? Please, more 
experienced developers/politicians chime in.

Thanks,
--Sean

On Mar 18, 2004, at 2:56 AM, Paul Boddie wrote:

> Ian Bicking [mailto:ianb@colorstudy.com] wrote:
>>
>> Paul Boddie wrote:
>>> More self-promotion, but what do you think of the WebStack stuff I
>>> announced on PyPI?
>>
>> It kind of opens all sorts of questions.  For instance, it's not
>> unreasonable that Webware could run under mod_python or Twisted (I 
>> think
>> a mod_python version existed a long time ago, and I experimented with
>> running it under Twisted a while ago as well).  (And Quixote already
>> does this in a less experimental fashion)
>
> To me, running Webware on top of another framework seems only to have
> deployment benefits, although one could easily say the same about 
> WebStack.
> However, Webware also ties the developer to a way of working which 
> carries a
> lot of semantic baggage - the servlet model, threading, and so on.
>
>> So, Quixote, or a more developed Webware, or a bunch of other
>> frameworks, could each be a kind of compatibility layer of their own.
>> Well, they *could*, but I don't think it's that easy.  But why not?  
>> I'm
>> not up to figuring out quite why right now -- but I think it has to do
>> with fuzzy layers.
>
> Yes, one could argue that hiding the special parts of frameworks or
> correcting the behaviour of such frameworks is the wrong solution to
> whichever problem one is trying to solve.
>
>> It seems natural that a framework could support one of several
>> underlying layers (e.g., Apache and Twisted).  But the layers aren't
>> very firm (what's "underlying"?).  Can Quixote work under Webware and
>> vice versa?  Or something heavier, like Zope?  And what does "work"
>> mean, anyway?  Perhaps that a URL space is segmented off, delegated 
>> to a
>> subframework.  Or by extension, ala Apache?  What about the frameworks
>> intermediate work getting to that subspace, like if Zope 
>> authenticated a
>> person at a higher level in the URL?
>
> Actually, the issue here seems to be how deep your frameworks are. Most
> Python frameworks seem to aspire to "deepness", covering everything 
> from
> socket communication right up to session management and application
> semantics. What I'd rather see is a collection of layered frameworks 
> and
> components which each do their bit of the job. WebStack mostly sits 
> above
> the communications layer, using the existing frameworks for that layer 
> and
> reusing other parts of those frameworks for higher level features that
> should arguably exist elsewhere.
>
> Above WebStack should be components which interpret URLs, control 
> access to
> resources, and provide the application-level services. A 
> counterexample of
> such an architecture is "Zope plus Products": by the time a Product 
> instance
> gets hold of request information, a lot of the decisions about where 
> that
> Product instance resides in the URL space have already been taken, but
> that's arguably the whole nature of Zope and the way it works and is 
> just
> one reason why some people don't really get on with Zope.
>
>> I don't know... I don't think it's necessarily *that* hard.  But we 
>> have
>> to think recursively somewhere in here, instead of layers -- we can 
>> only
>> build on lower-level layers for a while, at some point peers have to
>> work together in a friendly way.  In this case that would mean running
>> Webware ontop of WebStack ontop of Twisted, or seemingly silly things
>> like that.  But it's not really that silly, because I suspect it would
>> be fairly useful.
>
> I'm not advocating a Web frameworks equivalent to User Mode Linux. ;-)
>
>> But I'm not exactly sure how reasonable it is -- maybe it would be
>> better to decouple frameworks and separate layers so that this doesn't
>> all have to be so vague, and so we can feel more confident in how 
>> things
>> will work together.
>
> I'd certainly advocate such an approach instead, however.
>
> 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/lucid%40escex.com
>


From janssen at parc.com  Fri Mar 19 15:16:07 2004
From: janssen at parc.com (Bill Janssen)
Date: Fri Mar 19 15:16:26 2004
Subject: [Web-SIG] Shameless self promotion, and serious question. 
In-Reply-To: Your message of "Fri, 19 Mar 2004 08:57:40 PST."
	<88740DF1-79C6-11D8-AEC9-000A95C48278@escex.com> 
Message-ID: <04Mar19.121611pst."58611"@synergy1.parc.xerox.com>

> But what I've noticed is that there are spurts of activity on this 
> list, but no progress. Perhaps if someone actually coded something and 
> allowed others to play with it, some progress would be made.

Hear, hear!  Although, I think that's really only interesting if
there's an associated PEP.  There are plenty of things to play with --
I recommend Medusa and Twisted, for instance.

Bill

From paul.boddie at ementor.no  Mon Mar 22 05:58:33 2004
From: paul.boddie at ementor.no (Paul Boddie)
Date: Mon Mar 22 05:58:44 2004
Subject: [Web-SIG] Shameless self promotion, and serious question.
Message-ID: <FD72AF7813F1294C95279EC6D9784A2F4B81AC@100NOOSLMSG004.common.alpharoot.net>

Lucid Drake [mailto:lucid@escex.com] wrote:
> 
> Less talk, more action.

Ahem!

> At the risk of putting myself out there as all talk and no action, I 
> think it would be useful for those on this list that have a strong idea 
> about what should be added to the Python standard library, to post 
> something that people can play around with.

Yes, that was my intention.

> I am by no means an expert in the world of web programming, but I am 
> learning, and I do feel the need to have a better set of standard tools 
> in Python for developing web applications. I just don't have the 
> knowledge or expertise to develop something myself.

But that's alright. You're in a good position to give the more experienced
developers a reality check, to tell them what makes sense and what could be
made easier or more obvious.

> But what I've noticed is that there are spurts of activity on this 
> list, but no progress. Perhaps if someone actually coded something and 
> allowed others to play with it, some progress would be made.

Well, my contribution was really just letting people in on what I've been
playing with - something I find useful for my own purposes and which might
possibly be useful for others.

> I recall hearing the argument that whatever is developed shouldn't 
> break current frameworks, or force them into a model they don't want to 
> use. My question is, why would a new module break or force anything? 
> Won't the original modules still exist?

That's why I've taken the approach to build on top of existing frameworks,
at least for the time being. Persuading the developers of existing
frameworks is likely to be quite hard because it involves them taking in
code that will lead to more maintenance for them, and since many people who
are up close to any given framework are likely to favour the particular
development styles and practices of that framework, they aren't likely to be
so interested in standardised, framework-neutral APIs that don't expose the
fancy features that they've been promoting.

> In addition, even if the new proposed way of doing things breaks a 
> framework, how long would it REALLY take for the framework to 
> accommodate the changes?

With WebStack it wouldn't matter - just bundle it with your application and
deploy on top of a supported framework.

> All this talk is going no where, what ever happened to experimentation? 
> Create something, test it, use it, stress it, and learn by doing. Less 
> abstract design and more progress through action please.
>
> Am I right? Wrong? Not seeing the entire picture? Please, more 
> experienced developers/politicians chime in.

If you want something to play with and have some frameworks installed (or
even just have the standard library, since BaseHTTPServer counts as a
framework), try out WebStack:

  http://www.python.org/pypi?:action=display&name=WebStack&version=0.2

I'm not suggesting that it's the right way or the best way, or even that the
API it uses could eventually be directly implemented by some framework or
other, as the layer of "translating" functionality between WebStack and such
a framework just melts away, but I think it does count as a possible
reference point that people can either identify with or distance themselves
from.

Paul