Comments on Dave's Blog: JavaScript rules

I like the idea of having a more advanced, Smart F...

2009-08-10T03:34:49.992+10:00

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 :).

To be clear, this would not be the only interface....

2009-08-09T10:25:54.421+10:00

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've been using the current Marco Polo beta fo...

2009-08-09T01:28:46.446+10:00

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.