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
