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

[Peter Scott]

At 11:08 AM 12/2/2002 -0800, Darren Duncan wrote:
>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?

Apples, meet oranges.

>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.

If this differs semantically from "Abstract" then the distinction is too 
subtle for me, if not everyone else.

>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.

This is all too reminiscent of angels-on-pinheads discussions.  If any 
clear answer stood out for me, I would have given it, but at this point, 
the possibilities all look pretty much the same to me.  I think you could 
make any of them stick.

That may not be helpful, unless it just encourages you to pick one and live 
with it instead of worrying further.


Peter Scott
peter at psdt.com
http://www.perldebugged.com