Thanks Chris (and to Alex who replied off-list). Since you can assign an arbitrary number of inputs and outputs I'm using the JS module as a register where lots of things wire in and out. I'm sure there's a more efficient way to do it (writing a custom QCPlugin?) but it seems to be working well enough for me at the moment.
For simple state management, this is probably not going to be a significant load your composition. I've done a few state-based compositions using this method as well, and it's been fine.
For more complex state stuff (physics sim, particle sim), you'll probably be disappointed :)
Well, as you mentioned, in safe mode, when you're viewing a qtz, it's sandboxed anyway (and if it's not, it means you're running an executable, in which case it's no more or less secure than anything else you d/l and run), so I guess I'd say it's neither here nor there.
I guess the rationale was a bit like this (mind you, this is wild speculation, but it appears to be the pattern, for now at least):
(You're correct in your reasoning, by the way. I'm not disagreeing)QC doesn't have anything that can output to anything other than MIDI, OSC, and the graphics card. (by output, I don't mean published outputs). There aren't any patches that can write to the harddrive, preferences, etc., and the ones that can read from the harddrive tend to be limited (XML parsers, image/movie loaders, directory scanners that only find certain types of files). This means that even if you fire up a malicious composition in a non-sandboxed environment, the worst that can happen is someone can crash the app (oh darn), slow the machine to a crawl (annoying), or try to gain access to sensitive files (user photos, videos, and preferences, which are all supported by QC) and ship the data off to a remote server via the image downloader combined with specially crafted URLs. While possible, its quite cumbersome and not a huge hole that needs to be closely guarded against (in a relative sort of way).
With a shell command patch built-in by default, suddenly that all changes very quickly. RootKits, paired with downloaders and settings changes, are trivially possible with shell commands. Suddenly, mistakenly opening malicious compositions goes from "LOL, they stole a picture of me and my dog" to "Holy crap, they installed backdoors, and started scripts that ship off my firefox saved passwords and history files (or safari equivalents, if those exist?)". Even a juvenile "rm -rf /" [delete everything recursively; don't try that at home] would be a disaster, and might also wipe out an attached Time Machine, making it particularly painful and inconvenient. (Granted, some real- world problems, like identity theft, might plausibly happen under the first case, but they're not very likely unless a sloppy app records that sort of stuff in plaintext (instead of in the keychain, where it belongs)).
I'm thinking it's that radical shift in risk to the user and the machine that makes Shell Command an intentional omission from the standard patch library. The world may never know...
Thanks, I saw the plugin but it took some searching to find out how to install them. :) Also found out how to enable the the private patches (many of them that look pretty useful) on Kineme, so thanks for that as well!
No problem :) There's some fun stuff in there, out of the box even :) -- [ christopher wright ] [email protected] http://kineme.net/
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Do not post admin requests to the list. They will be ignored. Quartzcomposer-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com This email sent to [email protected]
