Hi folks, HDBC has been out there for quite some time now. I wrote it initially to meet some specific needs, and from that perspective, it has been done for awhile. It is clear, however, that there are some needs it doesn't meet. Most of them relate to specific backend driver items. I'd like to start some discussion in the community about what the future of HDBC and its backend drivers ought to look like. Some models might be: 1. I continue as maintainer for HDBC and HDBC-{postgresql,odbc,sqlite3} and act as patch manager/gatekeeper for patches that are discussed on some public mailing list. 2. Interested parties adopt the backend drivers while I continue to act as maintainer/patch manager/gatekeeper for HDBC itself. 3. Interested parties adopt all of HDBC and maintain it I am not expressing a particular preference for any of these options; just putting them forth. Here are some of the current issues I am aware of: 1. I have no Windows development platform. I can't test the releases on Windows. Many Windows users don't have the skill to diagnose problems. These problems do eventually get fixed when a Windows user with that skill comes along -- and I appreciate their efforts very much! -- but it takes longer than it ought to. 2. The ODBC documentation is monumentally terrible, and the API is perhaps only majestically terrible, and it is not 100% clear to me all the time that I have it right. A seasoned ODBC person would be ideal here. 3. Issues exist with transferring binary data and BLOBs to/from at least PostgreSQL databases and perhaps others. There appear to be bugs in the backend for this, but BLOB support in the API may need to be developed as well. 4. Although the API supports optimizations for inserting many rows at once and precompiled queries, most backends to not yet take advantage of these optimization. 5. I have received dueling patches for whether foreign imports should be marked "safe" or "unsafe" on various backends. There seems to be disagreement in the community about this one. 6. Many interactions with database backends take place using a String when a more native type could be used for efficiency. This project may be rather complex given varying types of column data in a database -- what it expects for bound parameters and what it returns. The API support is there for it though. 7. Various other more minor items. Thoughts? -- John