Uncle! Uncle! Uncle!

I guess, Helen, that I deserved your OT admonishment for making a
public display of my ignorance. I'd thought that Doug and I were
harmlessly filling the void in this long holiday stretch.

OTOH, Thank you for such a lengthy yet concise, helpful and
well-written review of our OT discussion. You must care about the
topic or you wouldn't have taken the time to write. You do have a
sense of humor, also -- "So, your mission, should you decide to accept
it, is to..."

Thank you,

Pete

P.S. - I have no affinity for .NET. I still can't figure out what its
value is. Just the tools handed to me at work, here. I had the luxury
of picking the database - Firebird!

--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@t...>
wrote:

> At 09:19 PM 27/12/2004 +0000, you wrote:
>
>
> >We may be off topic, Doug, but we're the only ones posting this
> >afternoon.
> >
> > > I don't think the app server is an ASP.NET app. It is a service
> >which runs
> > > alongside the DB and interfaces with ASP.NET apps. No user interface
> >at all.
> >
> >This is a valid Firebird support issue, I should think.
>
> No, it's not. Firebird provides the data storage layer of a properly
> layered system. Above that is the data access layer, which Firebird
> provides by way of the API. That is Firebird's window to whatever the
> upper layers throw at it. The language that the upper layers talk

to the

> database engine is SQL.
>
> Above that (usually) is the data access interface, which can be as

OO as

> you like (and the best ones are highly OO). Above that are application
> layers...somewhere between this point and the endpoint are the

input/output

> layers - the client application, including web browsers.
>
> >Externalizing some of the Firebird database activity in the form of

an app

> >server
> >must be a frequently discussed topic.
>
> Sure, application layers are what rule most of our lives here. But

they

> aren't the business of a database engine. Its business is to manage
> abstract structures called databases and to process requests from
> application layers. The database engine is neutral about where

requests

> come from.
>
> Firebird injects its own layer - stored procedures and triggers - to

give

> you the option of internalising some data operations that must rule the
> data layer regardless of the application layers. PSQL supports the
> objective of making the data layer independent of the application
> layer. It makes the business of data operations more efficient,
> predictable and faster. It reduces the amount of activity that has to
> cross the wire. It provides a way to centralise the behaviour of
> data. The cost is loss of genericity - you can't depend on all

these good

> things if you want to have application layers capable of commanding

any ol'

> database layer.
>
>
> >So, if there is anybody still reading our thread, then I ask if

there are

> >app server tools available for Firebirders?
>
> Of course - there's a whole industry devoted to app server tools.

All are

> programming language-specific and operating system-specific. A few
> languages - such as Java and Python frameworks - inject an extra

layer or

> two to bypass (to some extent) developing or a specific OS or even a
> specific database engine. Many - like .NET, Java, ODBC - limit to some
> extent what your applications can realise of the data storage layer's
> capabilities, in the interest of presenting a generic interface to

database

> engines - "the tail wagging the dog".
>
> Firebird has strong language support for your beloved .NET - join the
> firebird-net-provider list and ask there about the .NET or Mono

frameworks

> that you are particularly interested in. The .NET providers are your
> window to application frameworks like ASP.NET. Likewise, Java -

Firebird's

> Jaybird provides interfaces for two JDBC standards and, behind

those, is a

> world of application frameworks. The forum for Jaybird is the
> firebird-java list. Likewise ODBC - see the firebird-odbc-devel list -
> Python, PHP, Perl....
>
> Because Firebird emerged from the Borland stable, there are also

many OO

> data access layers available for Delphi and Kylix and, beyond those,
> excellent ObjectPascal OO frameworks for n-tier applications.

There are

> forums for all of these layers.
>
> >I sure wouldn't want to create one from scratch - instructive as it

might be.

>
> It gets down to what language you are developing applications in.

Within

> that scope, you design your application layers to suit requirements.

So,

> your mission, should you decide to accept it, is to decide where you

are,

> where you want to go and to work out where you need to be to develop

the

> layering you need.
>
> Firebird doesn't care what you do. It listens to SQL because it's the
> lingua franca of mainstream database application development.

Internally,

> it does what it's designed to do - store and retirieve data, manage

client

> requests and keep the house in order.
>
> ./heLen