On Mon, 2007-12-10 at 10:39 +0100, Frank Barknecht wrote:
Hallo, Thomas Grill hat gesagt: // Thomas Grill wrote:
it's unfortunate that you are not thrilled using flext. Since flext uses the PD api to get lists or other messages into secondary inlets there's nothing to stop you from doing the same in psql. The magic words are "proxy objects" which you might find in the mailing list archive (or the flext source code, if you prefer that). Needless to say flext saves you from coding these things yourself in a time consuming manner and makes other things really easy, once you got it running. You could also compile pool then.
The Python and Lua objects also support arbitrary messages on their inlets. Both languages have DB modules for just about every DB, compilation of these externals only has to be done only once. But as everyone knows that I don't really understand why a DB external has to be a C/C++ external, I'll better be quiet now. ;)
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.
However, Lua seems a slightly different story, ([lua] doesn't require flext, and Lua is very lean) - I'm starting to be convinced by it. It might be interesting to recreate [psql] using lua and luasql, and see how it measures up in terms of portability, ease of distribution and performance. I just downloaded [lua], and luasql, and It certainly didn't take long to get these things working on a basic level.
Jamie