QUOTE(Dibrom @ Mar 15 2003 - 12:18 AM)
QUOTE
And my personal opinion about solving the scripting problem - formatting plugins. The script could include something like '$function(component,function,parameters', foobar would call the corrosponding component DLL with the function name and the parameters, the DLL would return a string, and foobar would put that in the output.
An interesting idea, but I think this would still allow for the type of problems that Peter seems to want to avoid, mainly that with this level of power in scripting, the possibility to freeze foobar with a bad script becomes much easier.
Yeah, but then it's the plugin dev's fault. Thus bringing us to...
QUOTE(Dibrom @ Mar 15 2003 - 12:18 AM)
QUOTE
It wouldn't have the problem with easily crashing foobar, or at least not the problems associated with that, because presumably, anyone who can write a plugin should know better than to complain to Peter when their untested code crashes his program.
Hrmm.. I do recall this very thing happening with one of the early fb2k plugins for which links were removed from this forum
While technically people shouldn't bitch at Peter, I'm not so sure it would actually happen that way. No matter how clearly you try to point out possible risks or problems, people still seem to find a way to be surprised when it happens.
Heh. I was actually referring to the fact that if you have to write a DLL to crash foobar, then you are either (a) competent, and thus won't do it, (B) incompetent, but smart enough not to give other people your crappy code or complain to peter, © incompetent, and stupid enough to complain to peter, or (d), incompetent, and stupid enough to give people your crappy code anyway. In the first two cases, power to them. In case ©, well, at least they can be publically humiliated, and are a minority besides. In the final case, which is hopefully also the least likely, well, there's not much that can be done aside from judicious application of various forum admin's censoring abilities. Seeing as the problems that have been had in the past with bad plugins seem to have stopped, the class c & d devs apparently have learned their lesson.
QUOTE(Dibrom @ Mar 15 2003 - 12:18 AM)
QUOTE
It wouldn't have issues with bloating foobar, because all the code would be in a seperate file.
True, though I don't think that adding the type of functionality necessary to have something like an $eval function (which would allow for recursion) would really add too much bloat though.
A literal $eval function wouldn't make much bloat, correct. But if every possible eventuality that would lead to crashes were caught, then it might. I don't have much experience in that area, so I could be wrong. In any case, $eval is probably a bad idea anyway, so it doesn't matter much.
QUOTE(Dibrom @ Mar 15 2003 - 12:18 AM)
QUOTE
And if someone wanted to get really crazy, they could write their own script language as a function. Then they could implement anything from Perl to COBOL to Brainf*ck.
It would be pretty cool to have a plugin which could leverage the power of languages like Perl or Python for string manipulation. I wonder if the current SDK would allow for something like this.
I don't think the current SDK could allow for this - at least not without *really* cheating. Basically, it would involve making a plugin that adds a metadata tag to each file containing whatever the plugin wants to generate, probably by calling an implementation of whatever scripting language it wanted to use, hooked to provide the metadata already in the file. You'd then have to set the formatting tag to be a reference to the tag added by the script. If you feel like going even further and explicitly ignore SDK directions, you could go ahead and override the titleformat class that foobar has built in which takes care of that whole thing.
QUOTE(Dibrom @ Mar 15 2003 - 12:18 AM)
While we're at it, I think it would be rather cool if a plugin were made that would allow for loading an entire tagz display setup, along with fonts, color setups, etc, from an archive of sorts. That way people could distribute tagz display schemas easily. Functionality could even be added to select from different archives on the fly and have them update the playlist in realtime. Kind of like a skin browser, but just for tagz. It seems rather like a logical progression to me given the increasing complexity of the scripts we are seeing and the continued interest people have in creating new layouts and trying out new ideas. 
That's one thing I was thinking of. Does thinking the same thing as you make me a great mind by default?
