Add support for wildcards

Just a general statement regarding local benchmarks (Michiel, I know we slightly differ in this point as we have discussed it outside here some time ago):

Of course some little two or three lines of code never turn a site down. But it's the sum of all that makes the deal, or to quote a german saying: "Kleinvieh macht auch Mist".

I think we really should not add much more features to this module. Its original purpose was to do as few as possible, and NOT to get closer to core functions. The latter applies especially to the "more similar to hook_menu" and the slashes issue (I will link this comment in the related thread instead of duping it).

My point to this is: IF a developer wants to add features, he has all means to do this in his contrib module. And should he get to the point where the raw JS callback handler doesn't work anymore, he can still use index.php instead. So we should really decide a general direction for this module (for D6 and D7, as I think we will not need to get into D8 anyway): Do we want features or do we want as few milli and micro seconds per request? It is really not a rethorical question, but IMO the original intention was the latter choice. And, assumed we agree on "somewhere between these two", where and how do we want to draw a border?

At first sight, there is another alternative, that is splitting off into two branches or even make both paradigms configurable to the site builder (and include two "js.php" versions which might even be chosen and copied automatically based on this configuration), but then again, we would lose a reliable consistant API.

However. I may sound determined, or rough, or just picky. But it is my deep conviction that this module should be as featureless and as far from (feature-rich) default bootstrap as possible.

[edit]
Perhaps one last example to make a clearer point, as I just had a quiet hour to think a bit. I'll take our recent "access check" topic back as an example. Hope you won't mind (and yes I still agree that evaluating one "empty()" clause is really no deal, but it's a good figure.

Without the built-in access check option, one would have to do the following.

1. Add "user" to dependencies list.
2. Start his callback function with if (user_access('whatsoever')) {

- no big deal, and the choice "functionality vs. performance" is 100% in the hands of all developers using the module. This isn't the case if the function is integrated into js.php, because there is no way to undo an operation that has been performed (such as "module_unload", bad example). You know what I mean? Remember there are many many cases where user_access() isn't needed, and that matches for almost all functions not yet implemented.
[/edit]

Now you all :)