Content Type Based Editor Lookup, Take 2
Posted by pookzilla on March 19, 2005
The work is going well but I have concerns regarding the performance characteristics. The problem is images. In order to determine what image to associate to a file in the package explorer or navigator, we need to resolve the file to it’s associated editor. In the case of content type based associations this could potentially be very expensive. At the very least it will require reading the first bytes of the file (assuming a sensible content descriptor) and passing them to the various content describers associated with the content types in the system. If the file is in a network share, this could be very slow. Additionally, this pattern implies that the describer class is resolved, and therefor also implies eager plug-in loading. I have to wonder how badly this will impact downstream products.
We can solve the latency involved with calling the describer in several ways. We could throw a dummy icon back to the navigator (ie: a file icon with a question mark) and then resolve the icon in a background job, updating as it becomes available. I’m not sure how disconcerting this would be – icons flickering and changing as the user browses and such.
The second problem is not so easy to resolve. We could simply choose not to eagerly load a descriptor if its associated plug-in is not currently loaded. This means we’d get the editor mappings wrong for some files until their associated plugins were loaded via another means (actions, views, etc). This would be very confusing to the user. Perhaps the best thing we can do is advocate that features that contribute their own describers isolate those describers to dedicated plug-ins. In this way we can resolve their content types but not eagerly activate the bulk of their code.
RefuX said,
It seems likely (to me) that there will be other scenarios in the future where part of a plugin it going to be needed for plugin activation/participation to be determined.
If we start fragmenting our plugins now, we’re going to be in a world of pain soon enough.
Maybe we need to reduce the impact of “eager plug-in loading”?
pookzilla said,
Normally we’ve done a pretty good job of providing lightweight declarative alternatives to class activation (for instance, decorators). We need to consider such a solution here as well. Perhaps we could have matching rules declared in XML. As it stands, we do provide a resuable content describer for the most commonly required content type family (XML) – it’s just a matter of getting people to use it.
Anonymous said,
For those of us that hack *nix scripts, a regexp describer would be nice for matching shebang lines. Read a line (or configurable N lines/bytes) from stream, match with a regexp – voila, instant generic describer. Also good for signatures, XML and whatever else ails you. Granted, a bit slower than the binary describer, but good for EVERYTING.
Add A Comment