From kfm-devel  Mon Jun 18 20:58:44 2007
From: Kevin Krammer <kevin.krammer () gmx ! at>
Date: Mon, 18 Jun 2007 20:58:44 +0000
To: kfm-devel
Subject: Re: Swfdec/Konqi integration
Message-Id: <200706182258.48561.kevin.krammer () gmx ! at>
X-MARC-Message: https://marc.info/?l=kfm-devel&m=118220129411642
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--nextPart3036098.kOY3fQd6F6"

--nextPart3036098.kOY3fQd6F6
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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

> > 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 t=
he
> > new plugin specification.
>
> Mozilla asks the plugin the 'NPPVpluginNeedsXEmbed' value.

I'd like to apologize that I do not have any knowledge about the plugin=20
business sofar, but from the name of the function it sounds more like it wi=
ll=20
be returning a boolean value, not information about the required=20
toolkit+version.

Without this information the browser will have to start each plugin runner=
=20
until it finds one which can sucessfully load the plugin, won't it?

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

What's the difference of manipulating js objects and evaluating 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.

Is this for the browser -> plugin communication?

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

This flag allows the receipient of the message to not send a return message=
,=20
though it is still allowed to do so.
Non-blocking D-Bus calls are a matter of calling dbus_connection_send inste=
ad=20
of its with_reply variant.

If the plugin API does not expect any kind of error it is more or less an=20
implementation detail of the plugin runner. Might be helpful for debugging =
to=20
wait for returns unless this really turns out to slow.

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

I can offer to host any source archive on my freedesktop.org account, but I=
 am=20
not sure if there is a public area on the CVS repository where I could comm=
it=20
code.

In the case of an official freedesktop.org project it should be created and=
=20
spearheaded by someone with at least some under standing of this plugin=20
business, i.e. not me :)

Cheers,
Kevin

=2D-=20
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring

--nextPart3036098.kOY3fQd6F6
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBGdvIInKMhG6pzZJIRAtK8AJ9Vu1MKZ0XUX3iU4cG8cvES7xeKfgCfUBLx
MA99RpbO93ZO8rz/qiHmq+s=
=Er3K
-----END PGP SIGNATURE-----

--nextPart3036098.kOY3fQd6F6--