On Dec 10, 2007 2:40 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
Thomas Grill wrote:
There must be other externals using proxy inlets, probably zexy or other iem-based stuff.
right: e.g. zexy's [mulitplex] (aka [mux]) uses proxy-inlets.
there are 2 reasons why it is not in the externals-howto: #1 it would have complicated the howto needlessly #2 when i wrote the howto, i had no idea about proxy inlets and/or how to use them.
Yeah, I kind of figured that was the case.
having said that, i think it is usually a bad idea to all right-hand inlets accept arbitrary messages for _most_ objects (not for all). a message with a (nonstandard) "selector" selects a method of the object to be called and makes this explicit. e.g. it tells the object to do something (and eventually provides auxiliary data, to complete this task). if you are just passing around data to be collected by the object, there is already a certain type of message to do so: "list". it is possible to create a right-hand "list" inlet using the methods described in the externals-howto (iirc :-))
Well, there are a couple of issues at hand. The first is making the text look as much like SQL as possible. And the other is in dealing with commas. Having to prepend each SQL statement with 'list', while not a big deal, isn't really required. So why use it? This is why we need it to be an "arbitrary" selector inlet.
while i basically agree with matju, that a consistent use of the data-flow paradigm should not be made the holy grail (if we don't want to end up fighting green knights), i do think that we should bear data-flow (as opposed to control-flow) in mind and design objects accordingly.
As we are still in discussion about this, I just want to see if we can get what Hans is suggesting implemented, and then we can see if it is more/less cumbersome than what we have already.
Only way to find out is to do it...
Mike