> This is possible now by simply configuring a catch-all plugin to match > the empty suffix and removing the empty suffix from other plugins. So > it seems the problem is not that this is currently impossible, but > rather that it would be better to alter the configuration than the > plugin definitions. > > So we might have ParserFactory read a config file that maps content > types and url suffixes to plugins. Folks can edit this file instead of > modifying the plugin declarations.
I really don't like this solution to centralize this kind of informations. I think, it's the plugin responsability to claim the content-type/path-suffix it can handle. The problems today are: 1. In some plugins (powerpoint for instance), the plugin.xml contains only one content-type and doesn't contains path suffix (the originating problem of this thread could be easily solved by adding the ppt pathSuffix in the plugin manifest) 2. What to do if no parse-plugin match nor the content-type nor the path-suffix? I think Andrzej solution is the good one: Providing a default parser (doing its best to extract textual content). If this parser is not activated, then simply ignore the content. > It can also define default handlers > for unknown content types and unknown suffixes. This could either > augment or entirely replace the specifications in the plugins > themselves. Does this make sense? I really think that parse-plugins must specify the content-type and the path-suffix they can handle. No? Jérôme -- http://motrech.free.fr/ http://www.frutch.org/
