[Bese-devel] Re: UCW: The Future

[Nathan Bird]

Hail!

We've[1] been working with a framework built around ucw_dev. We use our 
own html generation stuff and have built on top of/replaced ucw's 
components. As such point 5 on modularization sounds like a great idea; 
I suspect it might be tricky to get Right. Most of our work is intranet 
only although we are currently working on a couple new projects that 
should be public (and fairly cool) in a little while.  Has anyone done 
much with any of the python frameworks? I know there has been some 
debate there between frameworks that provide everything and ones that 
facilitate hooking other libraries together. My perspective is that UCW 
would do better in the latter category.

I've not used ucw_ajax beyond poking at it for 30 minutes a year ago. It 
looked like it added/refactored some things nicely but that it was going 
to be a bit of work to convert our app to it... and then that amount of 
work just grew and we never switched. The good news there is that 
ucw_dev has proven to be stable and complete enough for us to build our 
own stuff on top of fairly well.

1) on stability sounds good. We've been talking about a buildbot setup 
around our stuff in the last couple of weeks too. ucw itself has been 
fairly good though-- that nothing in our branch of ucw has changed in a 
long time helps.
2) on reader syntax: somewhat unconcerned about using this in ucw code; 
in as much as reducing external dependencies helps point 1 and being 
standard helps point 3 it is good. My bigger concern is that I would 
like to see most UCW functionality provided by functions and classes. I 
like macros, but they seem to do best as veneer over functionality 
implemented in a more map-able form.
3) coding standards are cool.
4) 'No new features without docs' is probably a good dictum... now that 
we are already over most of that hump it matters less to me than it did 
before.
6) Everything we do uses a little javascript (and less ajax) this will 
probably expand in the future. Feelings are mixed on parenscript: I 
think it's tolerable and vaguely useful, others here think it gets in 
the way (especially now that we use cl-interpol as a standard required lib).

We currently use the httpd backend-- behind apache mod_proxy taking care 
of static files and ssl. We used mod_lisp for a while, but there didn't 
seem to be any performance benefit there based on an afternoon doing 
some rough benchmarks and my understanding of how the two codepaths 
differ. Mod proxy is standard and widely used/developed on; Mod_lisp is 
a custom installation (not to bad) and we've had one or two minor 
bugs/complaints.

Good to see this is going somewhere, hopefully we can help out on it too.

Nathan Bird

[1] http://www.acceleration.net Small company with 3 of us in the 
programming department (birdman and ryepup on #lisp) actively developing 
in Common Lisp (where we can).