Swfdec/Konqi integration

[koos vriezen]

2007/6/18, Kevin Krammer <kevin.krammer at gmx.at>:
> 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.

Mozilla asks the plugin the 'NPPVpluginNeedsXEmbed' value.

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

The npruntime offers plugins to get js objects (like 'window' and
'location') and manipulate their properties and call their methods.
The other way around is js bindings to the plugin.
We don't have an API for the first thing with kparts, we can only
evaluate scripts.
Anyhow something for this must be there too I guess. Ie.runner
exposing objects on a 'public' interface and browser side exposing a
npruntime variant.

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

I've used dbus_message_set_no_reply for all other cases. I thought
this will not block till it gets delivered at the destination. But I'm
not sure ..

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

That would be cool if you managed that. Let me know what I should change.

Koos

> Cheers,
> Kevin
>
> --
> Kevin Krammer, KDE developer, xdg-utils developer
> KDE user support, developer mentoring
>
>