[Bese-devel] UCW: The Future.

[burban at opopop.net]

"Drew Crampsie" <drewc at tech.coop> writes:

> Hello UCW users/developers,
> 
> The UCW project has been without direction for quite a while now.
> We've got one of the most advanced web application development

True I believe.

> environments out there, but it's not used widely, unstable,

Unstable? That I didn't experience with the simple things I have done
(see http://lisp.opopop.net).

> underdocumented and a bit of a mess. In order to alleviate this

Lack of more complete tutorials and documentation about how the pieces 
work together explains probably a lot about UCW limited acceptance 
so far. I found also the libraries used as lacking with regard to 
documentation.  

> situation, and to bring UCW into the mainstream lisp web world, I've
> volunteered to step in as maintainer/visionary.

Good to hear that! 
 
> I'd like to find out who's using UCW, how they are using it, what
> versions they are using (-dev, -ajax, -something-else) and what they'd
> like to see happen to the project. I'm going to be very aggressive in
> following a few ideals/guidlines for UCW that should make it more
> widely usable.

I use: latest ucw-boxset, ajax version, apache2 with mod_lisp and sbcl.

> 1) No arbitrary breaking. The test suite will be run and its results
> included in every commit message. the API will not change drastically
> all the time. Libraries will not be added/removed without taking steps
> to make sure things work. A buildbot will be setup. UCW will become a
> lot more professional.
> 
> 2) No reader macros, defclass*, cl-def or other 'syntax' will be used
> in the base library.
> 
> 3) An effort will be made to maintain a coding style consistent with
> that of the larger lisp community, as well as internally consistent.
> 
> 4) documentation will be written, and maintained. Now new features
> will be added unless documented and tested.
> 
> 5) modularization will be more explicit. I added a patch a while ago
> to allow a more 'plugin' like architecture, and this will be
> exploited. component libraries, form libraries etc will not be part of
> UCW proper as there are many possible implementations. Rather, a good
> flexible modular architecture will let the user choose to mix and
> match higher level code, be it Lisp-on-Lines, ucw-ajax, or
> what-have-you.
> 
> 6) Javascript will _not_be required, but will be well supported. A
> 'simple' set of ucw operators will be introduced and used for the
> examples and documentation.

I think of the above, 1) and 4) are the most important. Next is 5), 
and I am agnostic about 2), 3) and 6).

Regards.

-- 

B. Urban