Allowing plug-ins to augment `sniffString`

[skurfer]

Goals

• Quicksilver shouldn't need to know about plug-in specific types like formulas, remote hosts, terminal commands, etc.
• sniffString should be extensible without modifications to the core application.

Here's what I propose to bring this about.

Plug-ins

• Much like QSObjectSources and QSActionProviders, plug-ins would be able to provide a dictionary of QSStringSniffers. (An array would probably do.)
• Each QSStringSniffer would be a class with one method and one property.
• The method would take the string value of a QSObject, do its tests, and return a BOOL indicating whether or not the string matched.
• The property will be a set of example strings. These will be strings that should match, and (optionally) strings that shouldn't.
• Plug-ins would be able to define relationships between sniffers and types. As in "If sniffer X returns YES, assign these types". The type doesn't necessarily have to be provided by the plug-in in question.

  Quicksilver

• All current sniffString functionality would be broken up and added to different QSStringSniffers in the Core Support plug-in.
• sniffString will be modified to iterate through the available sniffers from all plug-ins. If one returns YES, iteration stops and the approprate types (as defined by various plug-ins) are assigned.
• We currently arrange tests manually so that the fastest ones will be tried first. For one thing, this is mostly guess work. For another, it won't be possible with various sniffers of unknown complexity from different sources. This is where the example strings come in. When all plug-ins have been loaded, every single example string will be run through every single sniffer and timed. The sniffers will then be sorted according to their average time and sniffString will try them in that order. As this ranking is unlikely to change often, perhaps it should be cached to avoid a delay on every start up.
• Maybe, in addition to the ranking, we should define a maximum acceptable time for a sniffer and refuse to load those that exceed it (and log a message to that effect).

I’m happy to work on this once we agree on an approach. Thoughts?

[pjrobertson]

I see you've assigned yourself to this, so I'll give you my thoughts (hopefully) before you've got too far. I think this sounds good, but I'm not convinced about arranging manually and testing like that.

My thought are that implementing this:

• will not give too many benefits (speed wise)
• it'll add to the startup time which will probably be more annoying than the few ms saved
• it may be difficult/fiddly to implement hence is it worth it?
• if this was really desired we could have some kind of list on QSApp.com with times which could act as the 'cache'

I definitely think it'd help out with plugins and things though. It'd mean we wouldn't have to define plugin's object types in QSTypes.h :)

[skurfer]

I'll give you my thoughts (hopefully) before you've got too far.

Haven’t even started. I was waiting for some input.

I think this sounds good, but I'm not convinced about arranging manually and testing like that.

Fair enough. I’m just paranoid about the processing on every keystroke aspects. Why don’t we get it working (with no sorting) and then, only if performance turns out to be an issue, we can look at how to order the sniffers?

[tiennou]

A few more points :

• Use the existing QSObjectSource infrastructure, since a plugin that defines an object source is likely to define its own "type" of QSObject and thus know if the string corresponds to its object type.
  • No startup cost w.r.t to loading Object Sniffers.
• Name the message something like -(NSArray *)validTypesForText:(NSString *)text which returns an array of compatible plugins types (or nil if the Source can't sniff that string).
  • I'm not sure about the array thing though, maybe the primary type only is good ? The message becomes -(NSString *)primaryTypeFromText:(NSString *)text.
  • I'd prefer an array, enforcing that the first item in the array becomes the primary type ?
• What about Objects that need a specific data part ? E.g Processes. If I type "TextEdit" while it's running, should the Process Object source sniff that string as a valid Process object ?
  • How is it supposed to set the correct data part in the Object's dictionary ?
  • What about creating duplicates (since I'm entering that as a string, and it could also exist in the Catalog) ?
  • How about naming the message -(void)sniffObject:(QSObject *)object so that the sniffer has complete access to the specific object it sniffs (meaning it can set all the data it will need) ? Maybe implement -validTypesForText: using the -sniffObject: infrastructure so that Sources with more complex requirements can override that instead ?

[stale[bot]]

This issue hasn't been updated in over 2 years. It has been marked as 'stale' and will be closed in 30 days. Please check whether this is still an issue with the latest version of Quicksilver. If so, update or comment on this issue to keep it open.