RFC --- new scripting extension sketches.

[koos vriezen]

2010/5/31 Maksim Orlovich <mo85 at cornell.edu>:
>> 2010/5/22 Maksim Orlovich <mo85 at cornell.edu>:
>>>> I am now working to get at least the window.location.href sequence
>>>> working. Until now, the deserializing from a dbusvariant to an object
>>>> fails.
>>>
>>> I didn't provide marshallers for Object and FunctionRef due to the
>>> pointers, as it's not clear what the right thing for them is.
>>
>> For kmplayer concerns, just remove the dbus marshallers. I don't need
>> them.
>
> To make clear, that applies to all marshallers, right?

Yes. Plus that its a kpart detail that probably doesn't belong in kdelibs.


> OK, and I think I won't need them for nspluginviewer either, it seems ---
> I think I will not use DBus for this at all due to the threading
> brokeness, but rather just a local socket, as it should be easier to get
> simple blocking behavior out of that.

Yes the BlockWithGui, that I use, is scary dangerous. Rather had
BlockWithSocketNotification.
Thought of that many times, but somehow it feels like a waste of time
to now invent a new protocol.
A peer-to-peer dbus connection looks to me the right way to go. Have
to look in the dbus code to see which of the low-level apis are
actually effected by this threading horror.

Which we noticed with dcop, collisions are very likely with
libflashplayer, ie. both side are in a code path that starts a call,
that a caller must be prepared for the case that not all data can be
written. And, which is obviously possible, that the reply is preceded
by a nested call.
Together with the nice argument iteration of dbus, quite some effort
to do it yourself.


>> I don't recall where, but I understood from the QDbusFoo docu that
>> incoming dbus calls (from plugin to part) don't auto  marshal complex
>> types. So the dbus decls are only useful in the other direction.
>>
>
>>> 1) Return values (including from enclosingObject/rootObject) are always
>>> ref'd by the producer
>>> 2) Arguments are to be guaranteed to live for the duration of the call,
>>> and the callee only ref's if it retains them
>>
>> That is what I proposed too. Currently however for 1), khtml calls
>> acquire on the returned value of 'rootObject', which it shouldn't
>> then, no? (Could be an unnecessary acquire/release pair caused by the
>> extra storage, which in this case, is pretty expensive)
>
> Yeah. That's fixed in my work tree, though there are some things to work
> out still. I've made some mistakes when writing the code first which will
> take some work to cleanup.
>
>
>> Thanks, your work is really appreciated.
>> I now have get/call to plugin also working, so youtube works with new
>> API. I haven't implemented the release/acquire though. Have pushed it
>> to kde svn, if you want to try, let the debug output not scare you :)
>
>
> I needed to do this:
> --- src/kmplayerprocess.cpp     (revision 1132909)
> +++ src/kmplayerprocess.cpp     (working copy)
> @@ -66,7 +66,7 @@
>  # else
>  #  include "knpplayer-liveconnect.h"
>  # endif
> -# include "callbackadaptor.h"
> +# include "scriptableadaptor.h"
>  # include "streamadaptor.h"
>  #endif

Looks right indeed .. hmm

> .. but I am mostly wondering about how much I should expect to work with
> this? I would like to test w/it when I am done adjusting KHTML...

Of course, ping me when I should rebuild kparts/khtml


>> The other day I remembered that in order to get kmplayer play flash,
>> one has to edit kmplayerrc:
>>
>> [application/x-shockwave-flash]
>> player=npp
>> plugin=/home/koos/.mozilla/plugins/libflashplayer.so
>
> Cool, thanks.


Koos