[PD] [psql] object hand-holding

Hans-Christoph Steiner hans at eds.org
Tue Dec 11 21:45:52 CET 2007


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






More information about the Pd-list mailing list