Actually, now that you mention it Neophytos is playing around with ideas for a persistence layer and intends to share them.
Query files aren't really a step in that direction in that there's no abstraction from the RDBMS. An abstraction layer's hard to do so I'm personally a bit skeptical that it can be done efficiently. aD's efforts weren't an unqualified success, apparently. Zope doesn't scale well but I don't know if that's due to the basic design of the persistence objects or due to other design issues.
RDBMSs perform best when you can bundle up complex set operations into a single query, and modelling this in a general way in an abstraction layer is not easy.
So, I'm skeptical but willing to be proven wrong.
Jun - as far as the future goes I'd like to move away from inline SQL altogether in the toolkit but I think we'll always support it in the db API. I've been thinking that we might get rid of the mandatory SQL parameter and replace it with an optional "-sql querystring" parameter. The idea being that without it a queryfile entry would be mandatory, and with it a queryfile entry would spawn an error. This would end the confusion you mention while maintaining the feature for those who aren't interested in RDBMS portability in their code, and for those cases where we build dynamic SQL.
