At 11:03 PM 2/26/01 -0400, Claudio Valderrama C. wrote:

>
> Let's face it, Jim: you have been sending subliminal messages to this list
>regarding NE and now that you have brainwashed people, you refuse to tell
>the price. Are you building the FB's ODBC driver at the same time than the
>NE's ODBC driver?
>:-)
>

Subliminal?

Netfrastructure is designed as a complete application deployment
platform for pure-play Internet applications. It contains what
is euphonistically called a "content store" with an integrated
search engine, a fairly sophisticated page generation engine, a
comprehensive "base application", and a Java virtual machine to
run application code. The overall goal of Netfrastructure is to
enable packaged pure-play Internet solutions to be installed
over the net, customized, and managed by browser literate mortals.

I thought it might be interesting to prattle on a bit about the
requirements for this application, and how these requirements
and the changes in available hardware have lead to a database
in the tradition of Interbase while radically different in
implementation.

Requirement: Application Customization

Its web presence is an organization's identity. Most organizations
will pick a fancy look and feel over a functional application.
Netfrastructure developers must be able to deliver high quality,
complex, comprehensive applications that can assume a client
specified look and feel without sacrificing application
maintainability. Or find another line of work.

Requirement: Platform independence.

People are funny. They pick operating systems based on tabloids.
Arguing is pointless; standardizing on one cuts the market by
two thirds. The Netfrastructure applications must be totally
platform independent. Java is the only game in town. Differences
among platforms must be invisible.

Requirement: Standards

Arguing about language features is a waste of time. Java fell
out of the previous requirement, Java has a database standard,
ego Netfrastructure is natively JDBC. It's good enough and I
don't have to argue with real people about it. I may extend it
here and there, but I do so quietly. And I don't care about
Java IDE. Pick one, anyone. I do byte codes.

Requirement: Search

Everybody knows that the Internet starts with search. Everybody, say,
but the SQL committee. Search must be native to the content store,
and must adhere to the conventions of the major search engines. Oh,
and fast.

Requirement: Namespace Management

An important goal is to host a major gaggle of application
instantiation on a single server. This dictates a multi-level
name space for the content store. And since we want to support
inheritance through the application hierarchy (base < app <
instance) while not requiring that application programs tweak
every miserable SQL statement for explicit schema names, this
means intelligent control of database (er, content store)
name space.

Requirement: Security and Roles

A pure web play means that the update side is as much a part
of an application as the display side, meaning part is public
and part is private, and keeping track of which is which is
life and death. Security is role based, for sanity, and the
same role model (sic) is used in appearance generation,
application control, and database access, which allows a single
application to serve administrators, designers, content
managers, identified users, and the unwashed to play nicely
and safely.

Requirement: Performance and Scalability

Directed content, role driven appearance, dynamic content, and
instance customization force 100% dynamic page generation. When
sessions carry state and potentially latent or active roles,
page caching is a non-starter. So it has to be fast. A comfortable
goal is 100 pages/second on a $500 server. No time to goof around.

Scalability means scathing performance on a cheap Linux box,
more on a multiprocessor, still more on a high end Sun. And if
that isn't enough, build in replication facilities.

Requirement: Developer Productivity

The target developer is a computing professional; there will NEVER
be a Netfrastructure for Dummies. Dummies use ASP. An application
starts with a data model, which the built in base application can
navigate with foreign keys and display with very general templates.
Application development should be a) data model design, and b)
specializing through overloaded templates the display of individual
tables. The rest is application specific special-casing.

Requirement: No Maintenance

Target host is an ISP with the technical skill to keep the A/C
working. Backups are automatic. No care and feeding. And
no sweeping (I am sick to death of sweep. It should have been
obsolete a decade ago. Never again. Never.).

Hardware:

Crapola computers come with 64 MB. More costs $.50/MB from last
weeks Sunday's flyers. There is more memory and cycles than network
bandwidth. Use it wisely.

Netfrastructure isn't Firebird:

1. Netfrastructure is natively SQL. No BLR crap this time.

2. Netfrastructure is a single process, heavily threaded. No
antiquated "classic" architecture. No external locks. Very
fine thread granularity. Threads are recycled.

3. The fundamental architecture of the content store is a in-memory
database back-filled from a persistent store. A scavenger thread
throws stuff away when it gets boring.

4. Netfrastructure is multi-generation in memory, not on disk.
Transactions clog memory, but memory is cheap. On commit updates
get flushed to disk or the bit bucket. If you run out of memory
and thrash, spend a $100 bucks and get more.

5. The application runs inside the content store. Netfrastructure
doesn't appear to have database procedures. In fact it's missing
non-database procedures. The Java virtual machines puts a safe
sandbox in the middle of the freeway. The real ResultSet object
is a microsecond from the application code.

6. Everything is cached. Especially compiled SQL statements.
Rather than expect application programmers to do smart things,
Netfrastructure does the smart thing letting the programmer
do the simple thing. Everybody is happy.

7. Almost no external utilities. With the notable exception
of a Developers' Workbench, everything necessary is built into
the base application include backup, restore, application packaging,
installation, application upgrade, security management, etc.

8. UDFs, not. But since the application code is in Java and already
inside the engine, who cares?

9. Foreign key enforcement, not.

10. Triggers are Java and generic. The same trigger can be called
pre/post insert/update/delete/commit. Hey, post commit triggers
are cool -- time to tell the world that something interesting
as important. Also gets around the stupid event alerter patent.
E-mail is a whole lot better than an event alerter.

11. Blobs and clobs (choke choke) are storage mechanisms and can
be used anyplace a string is used (except maybe sort).

12. "Upgrade" ddl verb is better way to maintain a data model.
Alter table is for the birds.

13. A "replace" dml verb is faster and easier that writing an "update",
detecting a no-op, and doing an "insert." Other than being easier
and much faster what's wrong with it?


Since this isn't a JVM or HTML generation list, I'll skip those parts.
But they're definitely way cool.

Ah, yes, Claudio, you asked about the ODBC driver. Of course.
The trick is making Firebird look like Netfrastructure. It's
the way of the future.

Jim Starkey