RFC: suggest DBIx::Layer or similar for module name

[Darren Duncan]

Hello.  I thought I would bounce this off of the omnimind to see if it has
some merit.  But first...

When it comes to naming a module, what kind of descriptive emphasis might
be better in a module name, between what kind of problem the module is to
solve and what kind of method is being used in the solution?

I ask because, while DBIx::Portable may be a good name regarding what the
module is to do, I am wondering if is too generic where people could say
"I've already seen that sort of thing before", given that a handful of
other modules are working on the same problem.  Instead, perhaps, I was
thinking that a name which incorporates my solution (which is unlikely to
be implemented differently over time) would be a better attention grabber.

Peter's suggestion of 'NoSQL' or the like is indeed less generic, but for
my purposes it is too descriptive, or not always correct.

My idea for a name like DBIx::Layer (or DBIx::Layered, or DBIx::ByLayer,
etc) came out this weekend and today when I was thinking more of what kind
of implementation and/or feature set I wanted to have.

My current idea is that my module is supposed to facilitate a multi-layer
abstraction of databases, with the layers ranging between code that knows
nothing about specific database engines (high abstraction) and code that
is highly optimized for a specific database engine (low/no abstraction).
There would probably be a middle layer that does some of each.  The idea
here is that my module should help manage and interoperate code in these
layers with the database and the main application.  High abstraction
layers would use zero sql, and low/no probably would use all sql.

The point here is to have your cake and eat it too.  In other words, to
have an application that is completely portable but at the same time very
fast and efficient.

Existing 'portability' solutions seem to take one tack or the other, but
not both.  Some implement a lot of features as pure Perl code and talk to
all databases using the lowest common denominator; what MySQL supports.
That approach is highly portable but it also has a tendency to be very
slow as well, with the Perl code doing a lot of work that the much faster
database engine itself should be doing.  Other solutions are thin and
fast, but they don't interface to a large number of database features; to
use those features they provide a 'bypass routine' where the app developer
essentially works at DBI directly as if the abstraction module wasn't
there, putting sql in their app which must be changed or put in 'if'
blocks depending on the database in use.

I could say more if needed, but that will be in a separate email.

So, based on what I have said, does a name involving 'Layer' or a synonym
thereof sound better than 'Portable' for what I have in mind.

Thank you in advance. -- Darren Duncan