Hi Kevin, 2007/6/18, Kevin Krammer : [..] > Awesome work! Thanks :-) > > :-) Anyhow it's a nice standin for nsplugin for the kde3 cycle for > > > > flash. > > (haven't followed development in trunk, so maybe it's too late already) > > Well, if possible we should have an option for a plugin viewer for the 3.5 > series, since this is what "enterprise" distributions will be distributing > for a while. Only this one is for new style xembed types. So we may have two. And its all mimetype based anyhow. > One of the comments on Zack's blog about browser plugins suggested that the > Mozilla/Firefox people might be interested in doing plugins out-of-process as > well and could even consider shared work on the plugin runners. > > Therefore I tried to (didn't check the sources thoroughly) extract the D-Bus > interfaces (see attachment) Koos used in the XML format used in D-Bus > inttrospection and added a few comments. Thanks. I hope you noticed it's more an ad-hoc interface now. Like you indeed noticed the 'getUrlNotify' and also 'finish' are odd and based on the fact that there is currently only one active stream. And streams are worked out sequentially. This should be changed to something like 'requestStream(streamid)'/destroyStream(streamid) for the plugin and streamDone from the browser side kpart. Also the to stdin streaming should be send in chunks containing a header of its size and streamid. Data must be retrieved from the browser side for eg. auth. reasons, though ideally I would like to stream directly from kioslaves of course. Nevertheless, it's the xserver that uses most of the CPU w/ flash movies. 'evaluate' is the only blocking call and should therefor have a non-blocking companion in case the result is not important. Btw. the way js objects are ref'ed is rather hacky of course. Anyhow, this all should evolve a bit by supporting various plugins. Thanks for your comments, Koos > Cheers, > Kevin > > -- > Kevin Krammer, KDE developer, xdg-utils developer > KDE user support, developer mentoring > >