Swfdec/Konqi integration

[Kevin Krammer]

On Monday 18 June 2007, koos vriezen wrote:
> 2007/6/18, Kevin Krammer <kevin.krammer at 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 the
> > 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 
business sofar, but from the name of the function it sounds more like it will 
be returning a boolean value, not information about the required 
toolkit+version.

Without this information the browser will have to start each plugin runner 
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, 
though it is still allowed to do so.
Non-blocking D-Bus calls are a matter of calling dbus_connection_send instead 
of its with_reply variant.

If the plugin API does not expect any kind of error it is more or less an 
implementation detail of the plugin runner. Might be helpful for debugging to 
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 
not sure if there is a public area on the CVS repository where I could commit 
code.

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

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/7d110368/attachment.sig>