On Nov 1, 2005, at 10:41 AM, Michael Watkins wrote:

> 'specialized application framework' ... seems you may be on track there
> Mario. One makes few choices for you; the other makes many choices.
> With
> Quixote you know what the publisher will look like, but sessions, User
> management, persistence are all unknowns.
>
> With qp you know what the basic web publishing environment stack will
> look
> like for any developer, from http through authentication to sessions,
> User
> and persistence. We might envision more sharing of 'applets' with such
> a
> backdrop. I wonder if that was one of the desired outcomes.
>
> .... ya just better like the principal system architecture choices of
> *nix and
> Durus! This is where I spend my time anyway, so these choices do not
> feel
> like limitations to me but no doubt they will to some.

Unicode out of eh box is a great thing, as is qpy playing well with
pydoc. Now the tempting thing is how best, while still retaining all
the simplicity, to add the most attractive features of a full stack web
framework. What comes to mind, taking also inspirations from cursory
looks at other frameworks currently en vogue, is:

- Automatic admin interface (as django does currently). Most of this
functionality may be had for very little, from using a durus layer that
provides for rich model definitions, such as Schevo (that does offer
this feature already for other UI contexts, and may be very easy to
have it available also for qp) or moellus (does not do that yet). What
would be really nice here is if this interface will actually capitalize
on the fact that the model is real OO as opposed to a relational
mapping (Patrick, any thoughts here?). This could be an important
advantage and distinguishing feature, compared to the other
frameworks... Also, the utility control scripts that come with qp
should be extended to also access control options offered by the durus
layer being used, such as to init, update, evolve, etc the db as per
model creations, extensions or modifications.

- Rich client-side components and widgets, ajax, ... i'd say go with
mochikit (as tg & subway have done).

- Adopt a convention, a la mvc, to easily support returning response as
data (json) or already rendered (similar to what tg does). I feel that
this however should only be a recommended "convention", and not an
imposition.

- Rich and automatic form and widget validation, or any other values
needing it, using the really nice spec module.

- Pluggable apps, or what you call applet sharing (similar to what
django does currently)

This would be really exciting....

mario