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.