Re: instant Lisp web application publishing

A> - flow of control. A web app is not just a bunch of dynamic pages; it
A> has to maintain some state (on session, db etc.) AND follow a certain
A> flow of control (e,g. first log in the user, then show page x, than
A> page y etc.). Making every function callable with any arguments, in
A> any order, is going to be messy IMHO.

the way i've desribed it is of REST architecture -- each resource is
addressed by URL, and there is no state on server (except, maybe, identity
of logged on user).
to my knowledge it's quite viable architecture -- you can make wide very
range of applications with it. as for erroneous URLs, it's not different
from traditional web servers -- if user clicks wrong URL error page is
generated.

however the way it works is different from way i've described :).
continuation style is used for now -- for each link and form there is a
closure that is invoked and link/form is activated by user. from developer
perspective it works fine -- it's very easy to preserve state as mere
lexical variables that are captured into closures. but this is problematic
for server -- closures eat memory, and it looks weird for users -- they
cannot bookmark URLs because closure ID is in them, and some "very stateful"
applications can have problems with backbutton etc..

i believe it's better to have a hybrid approach -- as much as we can in REST
style, and the rest via continuations.

but anyway, the way it works now seems to be quite usable (i've made some
little applications with it, though not "via web"), and that should be
enough for a prototype.

A> - debuggability/easeness of coding: (Lisp) people usually work with
A> emacs + slime or some other kind of IDE which makes some things easier
A> (e.g. compile or eval arbitrary forms with a keystroke, inspect
A> objects etc...) this would not be present in a web-only development
A> cycle.

eval/inspect is not a problem at all, interactive debugger is -- but
sometimes Lisp is hard to debug even having tools like SLIME, so i believe
simple error reporting + debug I/O (like trace) should be enough for most
purposes.
i've found that interactive restarts (like "specify other value") are not
useful for me in 99.9% cases, and SBCL's backtrace in SLIME looks like a
horrid mess, so i don't think it will be much worse with "via web" approach
:).

A> That said, your idea is less crazy than it seems ;) but perhaps I'd
A> organize things in a more layered fashion:
A> - at the core, some "essential" functions and macros such as db
A> access, html rendering (maybe widgets library too), state/flow of
A> control management.
A> - on top, an "environment" layer consisting of web-based debugger,
A> inspector and editor (not the size of a web-emacs of course - that
A> alone would require decades!)
A> - at user level, a web-development centered, dummy-friendly, lisp-
A> based hyphenated-word-named DSL which allows to code most common
A> webapps in itself (and of course allows experts to use the full power
A> of Lisp if they want)

right, layered approach should be more practical -- but i do not think of
particular use case patterns for now, and without particular patterns it's
hard to define layers and contents of these layers -- what should be in DSL
(or DSLs?) etc.
so my idea is to have totally chaotic thing for now, and then see how it
gets used by users (if it gets..) and getting feedback.

for example, i've found people here consider it as an application
development platform -- so we have discussion about debuggers, stateful
applications etc.

but my initial vision was database-centric -- you have a global database and
have different view to it. so it's like wiki, but a SemanticWeb-style
wiki -- not documents but data objects are stored in it. and certainly it
needs customized (user-customizable) views for these data objects. in this
case DSL should have features like easy templating for making views for data
queries, but not stateful application stuff.
as for use cases, people could use SW wiki to make stuff like
http://cl-user.net/ -- it's clearly better than unstructured
http://cliki.net/, and unlike "static" site it could evolve over time, so,
for example, for libs that are web frameworks we could define additional
properties (like if it supports continuations or REST, components), and draw
comparison tables, so people would be able to pick web framework in better
way. and persistence libraries could have their distinct features..

A> of course, all of this is HUGE.

i do not see why mentioned stuff is HUGE. certainly implementing it in best
way possible -- so it would be shiny, use fancy AJAX stuff all over place
and have visual form designer -- will take HUGE amount of work.
but just simple stuff that works should be relatively easy.


.