Testers wanted - new Python DHTML framework

[David McNab]

Hi,

I'm looking for adventurous pre-alpha testers for a DHTML (active website)
framework for Python I've developed.

Name:

- pyWeb

Features:

- easy to learn and use

- compatible with Python 1.5.2 and later (thus able to run on budget
web hosts which insist on staying with old Pythons)

- runs purely as CGI (or fastCGI)

- lets you build your pages with a simple, intuitive and coherent
document object model (DOM)

- extremely extensible, lends itself well to templating

- not a 'code within the html text' type of DHTML framework (like Spyce).
This one puts the emphasis on generating the HTML with python statements

- automatic retrieval and dispatch of browser cookies

- oersistent datastore that is stored on browser as compressed cookes.
secured via hmac/sha1, can store 10-25k of data on browser. Accessed in
python code by simply reading and setting attributes of an object

License:

- GPL

Info, examples, doco, download:

- http://www.freenet.org.nz/python/pyweb

All feedback gratefully received.

Cheers
David

[Moshe Zadka]

On Wed, 16 Jul 2003, David McNab <po********@127 .0.0.1> wrote:

- easy to learn and use
Have you demonstrated it? Did you give the documentation to someone,
and had him writing useful software? Or is this just an assumption
based on the fact that you find it easy to use, and did not have
to learn it?
- lets you build your pages with a simple, intuitive and coherent
document object model (DOM)
Is your DOM more simple, intuitive and coherent than minidom? microdom?
DOM is usually used in reference to the W3C standard. If you deviate
from the standard, it's probably best not to call what you have "DOM".
- extremely extensible
Did you try to extend it, and are reporting success? With two different
extension directions? Or is this, again, an assumption?
, lends itself well to templating
You mean each person has to implement templating on his own? Or does
it have a templating system?
- oersistent datastore that is stored on browser as compressed cookes.
secured via hmac/sha1, can store 10-25k of data on browser.
That probably depends on the browser. The standard states:
'''
* at least 4096 bytes per cookie (as measured by the size of the
characters that comprise the cookie non-terminal in the syntax
description of the Set-Cookie header)
'''
which means that cookies might get cut off or not stored at all by
the client. You might be splitting the cookies off transparently, which
should let you go up to 80k, but would probably make the job of anyone
wanting to send his own cookies hard.

The standard also says, however,
'''
Applications should use as few and as small cookies as possible, and they
should cope gracefully with the loss of a cookie.
'''
[All quotes are from http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2109.html]
Accessed in
python code by simply reading and setting attributes of an object
It also matters, probably, that you use a secure RNG generator for the
"secret" in the sha1/hmac schemes, otherwise a malicious client can still
force you to execute code. The RNG in Python, for example, is
'''
if a is None:
# Initialize from current time
import time
a = long(time.time( ) * 256)
'''
Since your server graciously sends the time, then if this is done via
CGI the client can try guessing several values for the time. CGI applications
usually run less than five seconds, so the client can even perform a brute
force attack.
All feedback gratefully received.

Enjoy!
--
Moshe Zadka -- http://moshez.org/
Buffy: I don't like you hanging out with someone that... short.
Riley: Yeah, a lot of young people nowadays are experimenting with shortness.
Agile Programming Language -- http://www.python.org/

[David McNab]

On Wed, 16 Jul 2003 11:05:51 +0000, Moshe Zadka paused, took a deep
breath, then came out with:

On Wed, 16 Jul 2003, David McNab <po********@127 .0.0.1> wrote: Have you demonstrated it? Did you give the documentation to someone,
and had him writing useful software?
That's what I'm doing *now* in *pre-announcing* to this ng.
Or is this just an assumption
based on the fact that you find it easy to use, and did not have
to learn it?
An assumption based on the fact that I used the same design style with
which I've written other python software (for which I've received
very positive feedback on its accessibility).

I try hard to write my software in a way that doesn't force its user to
contort his/her mind in umpteen weird directions to understand it.

I don't think I'm alone in the fact that I don't like having to smell a
programmer's dirty socks or analyse his pizza stains in order to
understand how to use his code.

- lets you build your pages with a simple, intuitive and coherent
document object model (DOM)

Is your DOM more simple, intuitive and coherent than minidom? microdom?
DOM is usually used in reference to the W3C standard. If you deviate
from the standard, it's probably best not to call what you have "DOM".

I'm using Document Object Model in a generic sense, similar to how the
word 'window' in a GUI sense doesn't always refer to M$ software.

I'm a bit cynical about DOM standards anyway, given how the client-side
DOMs between IE, Mozilla family, Konqueror and Opera etc are highly
disparate, and writing portable Javascript is such a CATPITA.

- extremely extensible

Did you try to extend it, and are reporting success?

Yes. One of the examples on the website (and the website which coughs
up its own source code on request) both demonstrate this.
With two different
extension directions?
What do you mean by this? What constitutes a 'direction'? Subclassing?

, lends itself well to templating

You mean each person has to implement templating on his own? Or does
it have a templating system?

User implements his/her own templating. In that respect, pyWeb can be
considered a bit more low-level than template-based systems. But for some,
the freedom to roll their own (and be in full control, and hot have to
conform to other people's abstractions) is a *good* thing.

Thanks for your feedback, moshez, but please recall that this is a
*pre*-announcement. The version is 0.1.0, not 1.0.

I know it's not immediately serving you the moon on a plate with a sprig
of parsely. But I feel you're jumping on it pretty hard, especially since
I'm only asking for testers. It's not like I've made any kind of formal
release announcement.

- oersistent datastore that is stored on browser as compressed cookes.
secured via hmac/sha1, can store 10-25k of data on browser.

That probably depends on the browser. The standard states:
'''
* at least 4096 bytes per cookie (as measured by the size of the
characters that comprise the cookie non-terminal in the syntax
description of the Set-Cookie header)

When the persistent data object gets pickled, it gets broken up into
cookies of max size 2048 bytes each. If there's more data, the pickle gets
broken up into several cookies then reassembled at the next request.

Apache seems to barf when the incoming 'Cookie:' header exceeds 8k, so
this appears to be the driving constraint.
'''
which means that cookies might get cut off or not stored at all by
the client.
Correct.
You might be splitting the cookies off transparently, which
should let you go up to 80k, but would probably make the job of anyone
wanting to send his own cookies hard.
My apache has an 8k limit on total size of all incoming cookies. If you
use more persistent datastore, you've got less space for 'physical'
cookies, and vice versa. That is the user's responsibility.

However, thanks for your noises on this - makes me aware that I should add
to the doco to explain these constraints to the user.

BTW - the persistent data object supplements raw cookies, it doesn't
take the place of them. The 'session' object contains a SimpleCookie
instance, the use of which is explained in the doco.
The standard also says, however,
'''
Applications should use as few and as small cookies as possible, and they
should cope gracefully with the loss of a cookie.
'''
[All quotes are from http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2109.html]

Accessed in
python code by simply reading and setting attributes of an object

I leave it to the user (pyWeb programmer) to make their own decision on
this. Similar to the fact that gcc could be used to write very insecure
code, but that is not the fault of the compiler developer.
It also matters, probably, that you use a secure RNG generator for the
"secret" in the sha1/hmac schemes, otherwise a malicious client can still
force you to execute code.

The 'secret' key gets chosen by the pyWeb programmer, with no prng
involved.

Granted, I should probably provide some scheme to make it easier for the
user to supply their own hmac 'secret', and possibly even assist them in
generating such.

Finally, note that there is no support for back-end database.

This is a deliberate decision, since it's targeted at people running
their sites on budget web hosts. There are hordes of hosts that offer
(mostly) great deals (eg CGI, 100MB storage, 10GB traffic) for around
$5-$10/month. But a lot of these hosts only have python 1.5.2, with no
MySQL interface module.

If you look through the examples, you'll see one which uses the Metakit
database engine (which can be uploaded in binary form to such hosts, and
which runs fine).

Cheers
David