Swfdec/Konqi integration

[Kevin Krammer]

Hi Koos,

On Monday 18 June 2007, koos vriezen wrote:
> Hi Kevin,
>
> 2007/6/18, Kevin Krammer <kevin.krammer at gmx.at>:

[...]

> > 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.

I understand. I even tried to get a bit of publicitiy for this new technology 
by blogging about it :)

Anyway, my above point is that if plugin developers move to this new 
technology (Adobe obviously is doing it for the next version of their Flash 
plugin), we will almost certainly need to be able to support it in the 3.5 
branch as well, since even if most our end user market is about to migrate to 
KDE4 once it becomes available, users of "enterprise" distributions and large 
deployments (e.g. Munich's Linux migration) will stay on 3.5.x a while 
longer.

> And its all mimetype based anyhow.

I am wondering how the browser will determine which plugin runner to start, 
i.e. which event loop/toolkit the plugin is expecting to have available.

My guess is that this is not covered yet and would have to be part of the new 
plugin specification.

> > 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.

I just wanted to add something a bit more abtracted to the discussion, i.e. 
experience on the xdg mailinglist indicates that such interfaces can easier 
be agreed on than any kind of "native" interface.

Basically there are about three points that have to be specified:

- plugin capabilites: how browsers get to know which MIME types a plugin 
supports and which toolkit requirements it has

- plugin control: basically the things the D-Bus interface is for

- data transfer: as Thiago already wrote, this should be handled with 
different means than D-Bus, e.g. a separate data connection on an unix 
socket, probably with the control connection being part of the D-Bus 
interface

> '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.

Hmm, aren't all the calls pretty much blocking in the native API?
Or do you mean it is the only one returning something?

> Anyhow, this all should evolve a bit by supporting various plugins.

My suggestion, from the point of view of someone watching things on the xdg 
mailinglist, is to be a bit more agressive than the usual KDE way.
For example by using bus names and interface names from the 
org.freedesktop "namespace", e.g. org.freedesktop.Browser.PluginHost instead 
of the "callback" interface, and trying to get the plugin runner(s) hosted at 
freedesktop.org

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20070618/ee37feca/attachment.sig>