The next step is to design the rules. In the past there have been many requests for more complex rule types (though people usually don't phrase it that way). Simple things like saying "when this device is *not* plugged in, ..." or "when *both* of these devices are present, ..." are impossible to do directly with the old MarcoPolo. I had originally planned to make MarcoPolo accept the wrapping of existing rule types in boolean operators (NOT, AND, OR), but now I think I have a better idea.
Here's the concept: embed V8, and allow rules to be written in JavaScript. There would be pre-made buttons to create standard matching rules so that most users wouldn't notice the difference, and power users would be able to write arbitrarily-complex rules in an expressive programming language.
Here's what a simple USB matching rule might look like:
function match(valueSet) {
if ('usb' in valueSet) {
var devs = valueSet['USB'];
for (i = 0; i < devs.length; ++i) {
if (devs[i].vendor_id == 0x046D &&
devs[i].product_id == 0xC03D))
return true;
}
}
return false;
}
That would be a bit unwieldily for something that should be easy, so there can be builtin functions:
function match(valueSet) {
return mp.hasExactMatch(valueSet, 'USB',
{'vendor_id': 0x046D, 'product_id': 0xC03D});
}
Of course then it can get complex very easily:
function match(valueSet) {
return mp.hasExactMatch(valueSet, 'USB',
{'vendor_id': 0x046D, 'product_id': 0xC03D}) &&
mp.hasExactMatch(valueSet, 'RunningApplication',
'com.apple.Xcode') &&
!mp.hasExactMatch(valueSet, 'RunningApplication',
'com.apple.iTunes');
}
That rule would match if my mouse is plugged in, Xcode is running, but iTunes is not running.
Anyone got any thoughts? Can you see this being beneficial? Or is it just massive over-engineering?
Posts
3 comments:
I've been using the current Marco Polo beta for quite a while now, and love an the intelligence it adds to my Mac. More flexible rules have been high on my wish list, but I am wondering how much advantage there is in implementing them as an embedded JS interpreter.
Take the example you provide; nothing in there could not be covered by the ability to use logical arguments and to group clauses of such arguments (essentially AND, OR, NOT and brackets), something that is easily done though a graphical interface, as OS X' Smart Folders definition bar shows.
Granted, scripting would allow even more complex clauses than that, but it would also add a thick layer of complexity. Using a JS engine for rules either will mean excluding less tech-savvy users from defining logical clauses (if there is no graphical interface for it; JS is not exactly a general knowledge scripting language), or having to implement a graphical interface on top of the engine, which sounds rather excessive.
Weighing the possible advantages (complex clauses which would not be caught by grouped logical conditions) against these disadvantages, I'd venture to say that, alluring as the proposal is from a technical point of view, it probably does indeed constitute over-engineering.
To be clear, this would not be the only interface. I would not expect the average user to ever see any JS; they would only use exact matching rules (like in old MarcoPolo), and the UI would automate and hide the JS behind the scenes.
I accept your point referring to Smart Folders. That was the original concept that inspired my thinking about how to approach this, and I thought that JS might provide the ultimate flexibility.
Perhaps some kind of trade-off: a Smart Folders-like interface for basic rules (exact matching, plus basic boolean operations), and also a JS rule option? Would anyone use the latter?
I like the idea of having a more advanced, Smart Folders like graphical interface to define rules. As to knowing if people would use the scripting layer, that is difficult to say. Adding such a layer removes its functionality one step as such, which is probably all right if it is only for the truly advanced cases; but there is also the question of the scripting language.
The stock scripting language on OS X is AppleScript, and in my experience, it is the only one non coders actually venture to use once in a while. I for one have shied away from learning a new scripting language just to unlock advanced functionality in an application, and although JS is certainly less exotic a choice than, say, Lua, that choice might constitute a second hurdle to widespread usage of the functionality.
Unless the whole scripting feature went more into the direction of creating packaged plugins for new Marco Polo behaviors? Just thinking out loud :).
Post a Comment