--- In Firebird-Architect@yahoogroups.com, Jim Starkey <jstarkey@...>
wrote:

> None have the computational power of JavaScript. And being able to
> return a cluster of objects to the client is very nice.

Sounds like you have more or less decided on JavaScript with a
standard db access API. This will certainly give Nimbus a short
learning curve for (web) developers. Not sure if it maximizes
developer productivity after the learning curve.

> Data will not be cached, only the prepared scripts themselves.

Clear. This means that the procedure will run on each invocation and
that instantiation overhead & runtime efficiency become issues. Scale
out will compensate, but within limits if you want to stay below
$15/seat operational cost. Or its back to memcached.

> I'm not adverse to defining a new language (I've designed at least
> a dozen), but the world doesn't really need another language if an
> existing language is sufficient. I've ruled out COBOL, ADA, and pdp-
> 11 Assembler.

Its about the concepts and food for thought, not about the languages.

> RESTful and transactional are mutually exclusive.

I think you are wrong here, when considering how transactions are
used nowadays ... quite unlike the 80's/90's context.

> Long running transactions... Let's see. In Rdb/ELN, Interbase,
> and Firebird, versions are stored on disk, requiring garbage
> collection. I got tired of hearing about sweep, so Falcon versions
> are only in memory. That leads to a major pain the butt when
> memory gets low. Nimbus has an even better solution that requires
> neither versions in memory or disk garbage collection.
>
> Yeah, I think I know that problem.

Thinking about transactions in terms of record versions is not
HELPful if you want to be RESTful :^). The paradigm has moved on.

> I tend to use a central string table, so there is only one instance
> of a string. This allows a hash on the string address and an
> equality match by address compare. It doesn't eliminate the hash
> lookup(s), but it reduces the cost to a minimum.
>
> In fact, however, most database transaction are contain little more
> than SQL and control flow, so in most cases, a lot of lookups are
> not required.

So is OO required then?

You are probably right, but I'm not yet convinced you'll get the
speed per dollar you'll want. On the browser JS runs into the
hundreds of kB, it probaly will on Nimbus. I hope the above choice
doesn't come back to bite you in the butt when Nimbus goes into
production. On the other hand, premature optimization is the root of
all evil.

> It also helps to think about the round trip each line of code may
> be eliminating.

Absolutely -- this is among what serverside procedures have been used
for ever since Sybase.

Paul