On Jul 8, 2010, at 12:48 PM, IOhannes m zmoelnig wrote:
On 2010-07-08 18:24, Hans-Christoph Steiner wrote:
Your example seems backwards to me. STDIN is definitely a hot action,
STDIN is far from being a hot action "definitely".
it's entirely at the process's disposition, whether it will do something
with the stdin or not.
anyhow, whether it's backward or not depends on your pov.
if you see [process] as an object that interacts with system-processes,
then i think my approach is straight-forward.
if you think of the object as being a representation of the process, and
thus the process being just another Pd-object, then my approach looks
backwards.
it seems like I (IOhannes) see this object as an interface to the
external world (ihde's "external" tool), whereas you (Hans-Christoph)
see the ibject as a way to internalize functionality into Pd (ihde's
tool "as an extension")
this basically means, that the question is not solveable :-)
and most likely the inlet that is going to be used the most.
or not.
i prefer to not make too many assumptions about what the users are going
to do, but rather try to make the interface consistent, regardless of
what they are actually doing.
i guess, people are using [shell] to startup an small script. and
startup the script again. and again, not worrying to much about the
output (mainly due to the fact how stdout/stderr are handled with [shell]).
if [process] is gooing to replace [shell], then people are probably
going to use the meta-inlets and -outlets most. so...
anyhow, the proposed object is merely an extension to the current
[shell]. you could even write an abstraction with the current [shell]
and some small wrapper-script that is more or less doing the same as
proposed.
it probably would be a good idea to keep compatibility.
I imagine
many users would never change the program that is being run. STDOUT
will most likely be the main outlet used, i.e the result, so that really
should be the first outlet. The process information is meta/info/status
stuff like in [hid], [comport], etc. so it should be the right outlet
like them.
i'm thinking more in terms of extensibility.
it seems like we all agree on the meta-outlet being a [route]able-message.
i think of the stdout and stderr as being messages without a given selector.
putting the stderr and stdout before the meta, makes it hard to add new
backtalk channels (e.g. pipes).
its similar to [route] where the reject-outlet moves to the right,
whenever you add new selectors. it's one of the behaviours that annoyed
me most.
(so that's an argument for both sides)
I could see combining the signal and process inlets into one second meta
inlet, but it seems to me that since there are just two messages (run
and signal), why not just make each have their own inlet and spare the
patcher from having to build up messages as much.
hmm, what's harder to do: create one of those fuzzy messages, or
fiddling with the tiny iolets?
personally i think the former is simpler to do.
in addition, i think that the former is simpler to read as well, as it
is an implicit documentation)
anyhow, i'm still convinced that creating and deleting a process (the
guts of this object) is "hotter" than sending data to it, which it might
or might not ignore.
fgmasdr
IOhannes