Hi Clark, Let me start by saying that I appreciate your efforts to bring the conversation back to things that can be done together. You started off with the suggestion of building up a new SQL-API, and then migrated toward using the SQLAlchemy code as a starting point.
I see where Jonathan is coming from with his NIH comment, and Mike is coming from with the term "magic" being overused. Though the tone of messages in this thread is not what some people like, I do think the discussion has been moved forward despite the tone. On 5/10/06, Clark C. Evans <[EMAIL PROTECTED]> wrote:
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.
Mike's subsequent message implies that the case is not completely closed. I can certainly understand that he would have misgivings in splitting the SQLAlchemy code base unless the gain is very clear. (Mike has stated previously that the ORM portion of the code is quite small compared to the overall base, which is probably part of the reason why splitting has never seemed appealing -- just download the whole package and only use the parts you want!) We're working in the world of liberally licensed open source software here. If Mike can't be convinced beforehand of the value of the project (or at least convinced enough to break it out into a separate beast), you (or Igor, more specifically) are free to take just the lower-level API and work with it as you please. You could consider it to be like a branch, that just happens to live in another repository. Though I can't speak for him, I'm guessing that Mike would be happy to answer questions about the code if there are things aren't clear from the docs. This would be a huge leg up, since this code has been getting a fair bit of use in a number of people's projects. By starting with that code base, the full opportunity to prove the value of the effort is right there. Regardless of what happens with that code, Igor could still fulfill the terms of the project, while focusing on fleshing out a working abstraction to support the full standards and documenting the adherence to the standard. There's an added bonus to an approach like this: someone in TurboGearsland has proposed writing a schema migration package for SQLAlchemy (and there's a mentor signed on for it). Almost all of that work has nothing to do with the ORM. This would give us two students trying to leverage and improve upon the same basic SQL layer. I, for one, would love to see that happen! Kevin ------------------------------------------------------- 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&kid0709&bid&3057&dat1642 _______________________________________________ Sqlalchemy-users mailing list Sqlalchemy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
