Michael,

You're offer to collaborate is wonderful; your instance on a real
specification before integration is perfectly reasonable.

I do see the primary distinction between the SQL-API project and
SQLAlchemy as one about specification vs implementation.  While the
users of SA are those building database solutions with Python, the
target audience for SQL-API are frameworks projects like SQLAlchemy.
You're analogy of WSGI to a web-server plugin is spot-on.

I see the primary deliverable as being a specification for plug-ins, and
other database tools.  Example "users" of this work would be things like
a schema migration tool, a graphical query builder, and pluggable database
"engines" for generating SQL a target database (as found in SA).

At this point I'm not exactly sure how this project will proceed.  We
will undoubtedly have to construct a reference implementation -- one
incorporating much of SA's fine work.   After the specification is
stable and if SA would like to test adoption, we could then talk about
making a branch to work on integration.

Thank you once again,

Clark

P.S.  If you're interested in tracking this project, the mailing list
will be at http://sqlapi.org/mailman/listinfo/sqlapi-dev; we are also
hanging out in #sqlapi on irc.freenode.net

On Wed, May 10, 2006 at 09:32:58PM -0400, Michael Bayer wrote:
| lets collaborate, but lets come up with some semblance of a real spec  
| first.   this before cracking open SQLAlchemy which in any case would  
| only be one particular implementation of many possible ones, and  
| shouldnt have to change its filestructure and release schedule around  
| just to meet a particular API specifcation.
| 
| in the real world, a finished SQL-API spec might even end up as a  
| compatibility layer in the ext/ package, sort of like a WSGI adapter  
| for mod_python.
| 
| On May 10, 2006, at 7:19 PM, Clark C. Evans wrote:
| 
| >Uncle!  Uncle!
| >
| >I think this conversation has come to a close.   The SQLAPI project
| >is based on the premise that a layer between DB-API and a full ORM  
| >would
| >be useful; and more specifically, that this separate layer should be a
| >distinct project with its own trunk and release schedule.
| >
| >I've had a talk with Michael, and he does not want to split the trunk
| >and release schedule to just contain these lower-level things.  So,  
| >this
| >effectively ends the debate on close collaboration.  I don't think  
| >this
| >effort can be successful if it is tied to the SQLAlchemy release
| >schedule, etc.
| >
| >That said, I'm sure there will be lots of opportunities to share in  
| >the
| >future.
| >
| >Best Wishes,
| >
| >Clark
| >
| >
| >-------------------------------------------------------
| >Using Tomcat but need to do more? Need to support web services,  
| >security?
| >Get stuff done quickly with pre-integrated technology to make your  
| >job easier
| >Download IBM WebSphere Application Server v.1.0.1 based on Apache  
| >Geronimo
| >http://sel.as-us.falkag.net/sel? 
| >cmd=lnk&kid=120709&bid=263057&dat=121642
| >_______________________________________________
| >Sqlalchemy-users mailing list
| >Sqlalchemy-users@lists.sourceforge.net
| >https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
| 
| 


-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Sqlalchemy-users mailing list
Sqlalchemy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users

Reply via email to