other formats (Re: [Dev] 4Suite RDF and ZOD)

[Jack Bell]

----GW-50187.21-Mailman--
Content-Type: text/plain;
	Charset="US-ASCII"

Eric Gerlach <egerlach@canada.com> said:
> I agree completely with your entire post, David.  The one thing I will
> add is the following, which I consider an important rule:  The
> performance impact of a layer is not negligible if and only if the
> layer itself is negligible.  That is to say, the only time a layer has
> a discernable performance impact is if it does nothing (i.e.
> delegation only).

And I am going to add a couple things to yours Eric, and then descend into
polemics. (Not that I am arguing with you or imputing that you have taken a
side, just making a point...)

Firstly, a thicker layer doesn't always mean a performance hit. That layer might
be doing object cacheing, better queries or other operations that result in a
performance *gain*. 

Secondly, a thin layer is good design choice only when you are implementing an
Adapter pattern between two otherwise similar systems. On the other hand a thick
layer is a good choice when it maps between a general implentation of the
requirements (the storage in this case) and a direct implementation (the view).
Here the layer is doing many things, some of which are orthogonal to the storage
design. A win even when there is a large performance hit!

Why is this? The software architecture we have been discussing here includes
things like MVC, RDF as a directed graph implementation, layered storage and so
on. These things are 'best practices' not because they result in efficient
implentations but because they result in flexible systems. They don't provide
the best design for any one set of requirements so much as they provide an open
design for the largest possible set of requirements. Even ones we don't know
about yet!

Were efficiency the first requirement of Chandler I would recommend that it be 
written in C or C++ using Structs in a memory mapped file to directly implement
the data structures coupled tightly to a view consisting of forms implementing
the data structures with the business rules coded directly to the widgets.

Such a design would be *very* fast! But what happens when requirements change?
What do you do when a low-level design descision results in a security hole?
Efficiency is good for some applications, but not for all.

This might seem like a strange way of putting it, but I see slavish homage to
'efficiency' as a kind of software engineering Calvinism. Personally I choose
free will. 

Jack William Bell

P.S. Why would I *ever* pass up a chance to sneak in a Rush quote?

----GW-50187.21-Mailman----