Flashplayer

[Maksim Orlovich]

>> Sounds like something is not letting go of a grab. Does kmplayerpart run
>> its plugin host as a separate process, or inside the konq process?
>
> Separate process

So it's konq/QX11EmbedContainer that's causing trouble/lockup.

>> And is implementing these enough for Flash not to crash?
>
> I never had a crash of npplayer, other than obvious temporary typos

I wonder if I screwed up then. The code is pretty complex (see the
attached diff). Of course, if npplayer is nicer, may be it can serve as a
base, if George doesn't mind. At some level, I'd like something like
kmplayer to be a reasonably core component for embedding, so people can
benefit from its cool compatibility/embedding features w/o going for the
app in keg.

>> Here, we have no type information on the arguments, to setup the
>> npruntime
>> structures. Similar stuff on put, get. Perhaps just pushing through the
>> LiveConnectExtension's notion of types along would be sufficient.
>> I think I'll e-mail my WIP patches here for further discussion once I
>> get
>> home.
>
> I rely on js' typeof to get the types. It's poor but the types in
> npruntime are int32, bool, double, string or object. I don't see how
> to detect argument type requirements of a certain call.

Well, you can't detect, but I figure it would make sense to have the
LiveConnectExtension pass them down from JS. I don't quite understand how
you would even do this typeof thing, I guess I should look at the code..

>> The part that I do wonder about is whether we'll ever have to deal with
>> passing a custom JS object to a call, or returning one... I guess you
>> already answered this since location is an object, but we may be able to
>> get away with special-casing one. Otherwise, one needs inter-process GC
>> and all other "fun" stuff one alluded to.
>
> I don't see why a call like document.plugin.setOutput(document.input1)
> would be a problem where document.input1 is of type
> NPVariantType_Object.

Well, you would have to have a wrapper for the document.input on the
browser end which forbids it from being GC'd, and connect it w/the
NPObject's refcount and all that. And there is a possibility of cycles.
(For more fun, note that one can theoretically pass functions across --- I
don't know whether that case is ever used, since supporting it will
require proxy objects on both sides).

> The reentrance works AFAIR w/ the Java plugin. The problem is when
> both side are in a code path that passes a call to the otherr side.
> That will deadlock. So only one side can block and I think that should
> be the konqueror side (with some sane timeout set). The plugin side
> should therefor start a local eventloop (we know by now that in
> konqueror this is deadly).

I don't see how it makes sense. If konqueror blocks, and the plugin makes
a call, what can you do? You can't interupt the plugin... Ahh. I remember
my discussion w/Thiago now.. What we have to do is make the return values
separate messages... So you get a call from konq, finish it up Q-DBus
wise, and afterwards, from the main plugin loop do npruntime reply. konq
is blocked meanwhile (hopefully w/o an event loop --- perhaps talking to
an another thread that's spinning in an event loop). Then the plugin's
call can be interpreted by konq as method invocation or a return, and
acted upon appropriately. Very CPSish

I guess that's about what you were suggesting..
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nsp.diff.gz
Type: application/x-gzip
Size: 9778 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20071019/a82bf76c/attachment.bin>