Allow plug-ins to define children based on URL

This might already be possible, but if it is, I can’t think of an example.

Currently, plug-ins have the ability to define children for something based on bundle ID. For example, the Safari module adds this under QSRegistration:

<key>QSBundleChildHandlers</key>
<dict>
  <key>com.apple.Safari</key>
  <string>QSSafariObjectHandler</string>
</dict>

The current behavior when right-arrowing into a URL leaves something to be desired. I would like to see something like this be possible in the plist:

<key>QSURLChildHandlers</key>
<dict>
  <key>http://qsapp.com/</key>
  <string>QSqsappcomObjectHandler</string>
</dict>

This would allow plug-ins to be written that understand a site’s structure or use its API directly, etc.

URLs that have no handler registered would fall back to the current behavior (which needs work, but that’s another topic). Perhaps ⌥→ should allow the user to bypass the special handler and use the default as well.

I haven’t completely thought this out. For example, what if a handler would work well for a large number of URLs. Like a parser that understood Apache directory listings and could remove all the “sort by” links from the results list and just show the file and folder links.

Also, I think this can be “faked” currently by adding some bogus object to the catalog and assigning it children.

Start by reading the QSRegistration handling of QSBundleChildHandlers and the Safari module's QSSafariObjectHandler registration. Trace how right-arrowing into URLs currently selects children, then resolve URL matching, fallback behavior, and optional bypass semantics. Done requires an agreed design before implementation.