Jim,

> Huh?
>
> Instantiation is:
>
> JWorld *jWorld = findWord(script);
> JInstance instance(jWorld);

Yes, but how much processing does it take to perform the object
instantiation in the second line? Set up the VM, initialise the heap,
define globals, etc. The more one optimises the runtime to run fast,
the more one usually increases init processing. You could use a pool
I suppose, or tie it to the db connection object if you have the
heavyweight connections of yesteryear.

> Not worth losing sleep over. Or spending $15/seat (????).

See earlier post about the financials of Salesforce, Netsuite, etc.
In a commodity world, cheapest wins out over time.

> Paul, RESTful is no state. A transaction is state.
> State != NoState.

We may mean different things. REST = Representational State Transfer,
it is all about state. For instance see:
http://en.wikipedia.org/wiki/Representational_State_Transfer
The confusion arrises from the RESTful requirement for a stateless
*wire protocol*

> In any case, an application server will keep a pool of open
> connections to the database, which also disqualifies it from REST.

Or you make the connection very lightweight, so that it can be
ephemeral.

> > Thinking about transactions in terms of record versions is not
> > HELPful if you want to be RESTful :^). The paradigm has moved on.
>
> It isn't that the paradigm has moved on but that databases haven't
> been able to keep up.
>
> The architecture that I expect to see for a long time is:
>
> Client (browser) => Application server => Database server
>
> I expect that responsible adults will give browsers access to
> databases around the time that hell freezes over.

Agree, agree and agree.

> Hundreds of kB to do what? What you're seeing is DOM (document
> object model), not JavaScript. JavaScript even with the core
> builtins isn't very big, and a useful subset is even smaller.

I wasn't talking about the JS system, but about the scripts. On the
browser, JS started as a nifty way to add some intelligence to web
pages; its designers thought about scripts of a few hundred lines
max. Then users started to stretch and stretch and stretch and now we
need V8 or TraceMonkey to efficiently execute the 65kB of script on
the average web page today.

I suspect the same will happen to your Nimbus procedures: developers
will stretch their use way, way beyond what you intended them for.

Paul