On Sun, 2011-03-06 at 15:34 +0100, Chris Young wrote: > On Sun, 06 Mar 2011 14:12:11 +0000, John-Mark Bell wrote: > > > I'm really not convinced that using the plugin hooks like this is the > > right way of solving the problem you appear to be trying to solve. > > Particularly, treating plugins as valid image content types likely opens > > a large can of worms (not least, as plugin support was disabled because > > it resulted in many crashes) > > Without treating them as images none of the plugin functions are > called for objects embedded on pages... although actually, I see that > is my mistake as of course plugins are usually embedded differently.
Indeed. > > Could you explain what it is you're actually trying to do here? > > > > If, as I suspect, it's to be able to dynamically support additional MIME > > types, then the better solution is to make the content type dispatcher > > able to accept runtime registration of MIME types. This is something > > that is planned, but won't happen until after 2.7 as it requires major > > surgery to the core. > > Yes, that's pretty much it. I was focussing on images initially in a > bid to remove some of the larger static libs from that build, as it > tends to get used on low memory classic machines. Ok. Sounds like we need to bump the priority of dynamic content handler registration, then. > plugin_handleable and treating plugins as images works for this, > supporting embedded audio might need plugin_open or the mouse action > function. Handling non-visual contents is a whole other can of worms. :) > The ordering of functions and some of the parameters were wrong for > RISC OS, but I suspect these are just things that hadn't been updated > along with the core rather than anything to do with the crashing. Yeah; that code simply hasn't been built for ages, hence why it gets broken every now and again. > I'll remove plugins from image_types to stop it causing more trouble. Ta. J.
