paulruizendaal wrote:

> --- 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.
>

I'm dabbling. A JavaScript interpreter is only a three or four day
project. I need something for benchmarking and JavaScript is no more
effort than alternatives.

I'm still on the learning curve. JavaScript is a more subtle language
than generally thought. Or maybe I should call in ECMAScript to avoid
Sun's trademark.

>
>> 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.
>

Huh?

Instantiation is:

JWorld *jWorld = findWord(script);
JInstance instance(jWorld);

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

>
>> 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.
>

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

In most cases, a script "transaction" will do a commit and that will be
that. But I don't want to constrain the protocol to require that.

In any case, an application server will keep a pool of open connections
to the database, which also disqualifies it from REST. And having to
authenticate each "transaction" seems like a gross waste of effort.

>
>
>> 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.
>

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.

>
>> 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?
>

No. Something that returned XML (or equivalent) would be OK. But
either XML (or equivalent) or a serialized object stream is necessary to
represent arbitrarily complex data.

> 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.
>

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.

>
>> 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.
>
>

--
Jim Starkey
President, NimbusDB, Inc.
978 526-1376