> 3) Programs imbedded in documents to be sent back to clients, like
> sophisticated forms.
Thanks, this breakdown makes thinking easier.
> Since #2 is the real efficiency-problem, it's clear that Tk isn't the
> problem, at least to me. The problem is the efficiency of the code
> runing on the server on behalf of the clients. Since the kinds of stuff
> I'd let people run on my server without checking it fall into a few
> categories, I would think I could extend my language to cover them
> efficiently, just imagining for 5 minutes off the top of my head.
I think we have the same concerns, but different emphasis. We are certainly
in agreement that whatever language is used for #2 it should be extensible
in the sense that it should be possible to recast frequently used operations
into fast primitives.
I've been thinking of using scripts like these to do things like watch
the documents on a server for changes or do other kinds of document
aggregation (i.e. index building.) Some people would put this into
the clients, but I like the idea of a client having the ability to
inject something into a server that says "do the following...". I'm
not sure how to build the response path for something like this in the
current http architecture.
I know this is getting towards robot-land... it's sort of like a
roll-your-own robot to run on the server.
And because I've been thinking of potentially long-lived server
scripts, and potentially a lot of them, efficient execution and
minimization of context switch overhead is a big concern to me.
(Especially as I want to see solid servers on inexpensive platforms.)
> > Ah, finally what I do want to talk about. But first, I think we
> > really need to understand how smart documents will interact with one
> > another or spawn one another, if they do so at all, or how cgi-scripts
> > interact with other cgi-scripts, if they do so at all.
>
> Yes! Yes! With a good interface between, the language matters much less.
The interface is the most valuable part; the languages may change, but the
interface will tend to remain for a long time. Besides, I find that clean
interfaces let people build interesting products in less time.
But I do not have a clear vision how these smart documents or server
scripts or whatever we call them are going to interact with one
another, or whether they should at all.
--karl--