On Dec 11, 2007, at 3:45 PM, Hans-Christoph Steiner wrote:
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.
I just wanted to add, I am not anti-python or lua or whatever. It's
just a practical matter. Pd is written in C, therefore it's going to
be much easier to manage Pd code written in C. C is a pain, that's
true, but that's what we got. Perhaps someone could write another pd
in Lua! :D
.hc
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
"Free software means you control what your computer does. Non-free
software means someone else controls that, and to some extent
controls you." - Richard M. Stallman
-
Hans-Christoph Steiner