Testers wanted - new Python DHTML framework

[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 <postmaster at 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