Re: [Chicken-users] A call to arms

[Andrew Gwozdziewycz]

On Thu, Jan 22, 2009 at 3:27 PM, Peter Bex <address@hidden> wrote:
> On Thu, Jan 22, 2009 at 03:01:30PM -0500, Andrew Gwozdziewycz wrote:
>> So, if you have to simulate features of the storage engine to get
>> compatibility, all you have to do is tell users that there are some 
>> limitations
>> to it. Give them the information to choose for themselves. But, on the
>> other hand, if they end up growing significantly, and decide to switch
>> storage engines from ASCII files to Postgres, why should they have to do
>> any more than recompile/restart with a different connection parameter?
>
> Because if you provide the same abstract interface to all the storage
> engines, you won't be able to leverage any of them to their fullest
> extent.  You'll always end up either abstracting away too many essential
> details, or provide a way around the abstraction, in which case it isn't
> complete anymore.

Certainly true, but let me ask you this. If you were planning to use an ASCII
file as a storage engine, what details would you include? Would you not
include a way to join other ASCII files, or do some sort of search? Would
you not build in 'grep' to do filters with regex?

The benefit of abstraction here is that we don't care about where it's stored.
If we care about performance, we're going to use the engine that best fits
the features we need anyway. We're not going to use ASCII files if we set
our data up in an entirely relational way, but there's no reason to not simulate
a feature that doesn't exist in an storage engine if it makes sense to use.

-- 
http://www.apgwoz.com