On Dec 11, 2007, at 8:29 AM, Frank Barknecht wrote:
Hallo, Jamie Bullock hat gesagt: // Jamie Bullock wrote:
Actually, please don't be quiet! When this was discussed some time
ago, you mentioned Python as a solution, and my feeling was that if I
write a piece and it uses some database connectivity, I don't really want to have to distribute a Python runtime, relevant Python SQL module, [py] and all the respective dependencies with it. I just (at most) want to include an external, and the databse library it uses. If I write a piece, I can't reasonably expect a performer to resolve all of this themselves - it needs to "just work". I also want to minimise as
much as possible the number of discrete components in the system that could possibly go wrong.That's quite sensible. As soon as a DB interface is involved, one already has entered dependency hell, so minimizig further dependencies may be a valid goal. However a dependency on flext is just a dependency at compile time, so it's not really an additional dependency at runtime. A dependency on Python is kind of a dependency at runtime, as you need a possibly large Python installation. A dependency on Lua is also a runtime dependency, however as Lua is small, including it with the binaries will make the runtime dependency not matter.
An immediate advantage of both Python and Lua is, that once the system is set up (easy with Lua, a bit tricky with pyext), the actual object code is just a textfile with a script. Especially as so far it's not even clear, how the SQL class in Pd should behave, this would allow rapid turnaround cycles in development. (For example I posted a working SQL object in Lua some weeks ago, and in Pyext some months ago, that took me about 20 minutes to write, including help-patch. In the case of Lua, I had never written SQL code in that language before. I wasn't so fast because I would be a genius programmer, but because the language is easier and no compilation is involved.)
For a general purpose DB interface I would generally still prefer Python because threading is possible, but if ease of installation is a higher goal, Lua IMO even beats C-externals.
Things are easy to compile only if your machine is setup for
compiling. Pd patches and binaries shipped as part of Pd are by far
the easiest to use. Getting distribution working in a non-trivial
task, so unless lua and/or python are built as part of Pd-extended, I
would not consider it easy.
Other than that, Python, PHP, Perl, Lua, etc all have native
interfaces to databases (some likely written in C), I think Pd should
also have a native interface for databases. Pd is written in C, we
have working C code, Pd externals written in C have a proven track
record of ease of use, so it makes sense to write this interface in C
as well.
That said, I think we have a solid interface sketched out, I think
it's time to write some code and try it out. I've started porting
the mysql external from Max to Pd. Let me know if you guys want
specific help with psql and sqlite. Ultimately, I think these all
should be part of a 'sql' library, and then we can also add the query
building objects too.
.hc
As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours; and
this we should do freely and generously. - Benjamin Franklin