RFC --- new scripting extension sketches.

[Maksim Orlovich]

> 2010/5/5 Maksim Orlovich <mo85 at cornell.edu>:
>> Hi.. Please see the attached file for what I sketched out thus far for a
>> replacement for LiveConnectExtension. It doesn't address quite a few
>> things
>> --- see comments on top --- but I figure I should probably get some
>> feedback before going overboard.
>
> - eval stuff, something like
>      bool evaluate(const QString &script, QString &result);
> for nsplugin this is a requirement, flash injects quite some js into
> the container page.
> Maybe add a script language as extra argument.

I meant mostly in terms of sync/async, and partly in terms of providing a
backwards compatibility wrapper over the old stuff (which I have to
re-study every time due to its weirdness). But on further thoughts, sync
would be better --- right now I have to block other I/O in nspluginviewer
in order to handle the javascript: url request eval safely anyway.

>
> - exception propagation
>
> returning false is an exception condition I guess

I meant in terms of NPN_SetException. Not clear when that can be called,
and what the semantics are. It might also be possible to stick stuff into
a return ScriptValue/QVariant to avoid all bool return/out-parameter
pairs.

> - ScriptValues, I suggested using QVariant and a user type for the js
> object proxy. Your ScriptValue class seems to be enough for nsplugin
> though. However if e.g. a kpart hosting app want to retrieve a QImage
> from a image viewer kpart, it can probably hack it in, but QVariant is
> definitely more friendly.

You might be right, though I am not entirely comfortable with generic
variants, as it's not clear what might go in them.

I suppose saying numbers + string + bool + a few custom types (object,
null, undefined) would be reasonable. It also does help dealing with
swizzling of pointers over DBus --- and thinking of that, how well does
QVariant work with dbus?

>
> The wrapped object table example seems to me unnecessary,
> nspluginviewer can use the NpObject pointer as objectid, the caller of
> a function should deref the arguments after the call, likewise for the
> result object as for property setters.
> The kpart object owner is indeed needed and should be packet in the
> parts own object implementation. In case of nsplugin, a sub classed
> NpObject and in case of khtml, a JSObject sub class, me thinks

A table is actually needed for both nspluginviewer and KHTML.
nspluginviewer needs it for function objects, which may  not be an
NpObject, but rather than NpObject + field pair. (And on that note, I
think we need to kill the function type --- we can't tell in advance if
something is callable in an npruntime plugin with certainty, as some
normal objects may support InvokeDefault). KHTML needs to keep track of
objects it handed out to mark them for garbage protection (OK, not
strictly needed, can do a gcProtect based on a refcount)

And also, I don't think any implementation I make will thrash refcounts
that heavily. Heck, in the common usage case, the old unregister would
have been fine, but I wanted to avoid making too many assumption.

It does seem like the example is indeed too heavy-handed though, and that
I should make refcount semantics (start-at-0) clear.


> What I miss is the back direction of this.
> So a kpart creates a ScriptableExtension object as QObject child.  The
> hosting application, when creating the part, calls

<snip>

>   bool setHost( ScriptableExtension *);

There is a way for this in the sketch, via the parent object, but what you
suggest is indeed much nicer. I think ScriptableExtension can just have a
field to store it.  For some reason I thought it couldn't be called early
enough, but of course there is a window between part creation and OpenUrl.

Thanks for the feedback,
Maks