RFC --- new scripting extension sketches.

[koos vriezen]

2010/5/18 Maksim Orlovich <mo85 at cornell.edu>:
>> The issue I think is that if the caller isn't interested in the return
>> value, a refcount of 0 means the allocated memory is never freed.
>>
>> I would think that the caller always is responsible for the live time
>> tracking. So get/rootObject/enclosingObject and the return value of
>> 'call', which all can return a Object/FunctionRef, should be ref'ed by
>> the callee before returning, so the caller can store it without
>> acquiring it, and should release it after use. Saves a dbus round trip
>> too.
>
> OK, I can make sense of this... Though it's actually less efficient for
> KHTML, which doesn't want an entire refcount, as KJS does proper garbage
> collection. (Right now you'd have a single reference count increment for
> base object, and one for each of function references).

But only short term, because you expected the caller to acquire anyhow.

>> My understanding for 'call' and 'put' argument(s) are that the callee
>> should only ref it when it wants to store it (obviously 'put' always
>> does that), since after the call, the passed object(s) might be freed.
>> I.e. the arguments are const. Which means that the caller can also not
>> pass a zero refcounted object, unless it checks that the refcount
>> hasn't become >0 (which it can't in the current interface).
>> Also the callee might want to acquire it, later on in the same call,
>> it decides to release it again, the object becomes dangling.
>> (Just to write down how I expect it to work, correct me if I'm wrong)
>>
>>
>>> Perhaps simply stating that you ref values you pass as arguments or
>>> return, deref those that you get as parameters or return value, too?
>>
>> See above, so no need to deref parameters I would think.
>
> Well, if the callee doesn't deref them, sounds like the caller should do
> so on objects it's loaning (and ref'ing to get a non-zero argument), no?
> I'd rather make it symmetric -- producer refs, consumer derefs....
>
> ... You might perhaps mean something like this: "It's the caller's
> responsibility to ensure that any objects it passes in last through the
> entire call, but the callee should acquire/release any objects it stored
> beyond that"? I am kind of getting worried about the complexity here ---
> sounds like an optimization rather than a clean API (perhaps because KHTML
> can offer the guarantee for free for its own objects) --- especially if
> you throw in cases like an object from KMplayer getting passed to
> nspluginviewer or such.

Its just like done in NpRuntime, NSGetValue callers are expected to
release the return variant and NSInvoke does not release arguments get
passed, it can use it during the call.
AFAIK, that is common sense programming.

Here a small analogy (sorry for its silliness)

// getter, return values
When Barney asks Fred for his bowling ball, it expect to get the ball,
not an empty bag whereon he must ask again for the real ball
(acquire). Instead Barney should return the ball after the game (ie
release it).
Barney, being the caller, is responsible for releasing the ball.
// call
Fred then asks Barney to clean the ball, and passes him the ball and
and some polish. Again, not an empty bag and/or empty can. Only if
Barney wants to keep the polish for after the polishing of Fred's ball
, he asked Fred for it (acquire)
Fred, being the caller, is responsible for passing real objects.

>>> e.g.
>>> static void acquireObject(QVariant)/releaseObject(QVariant), that
>>> call the appropriate virtual acquire/release on function/value types.
>
> OK, I convinced myself that was a good idea at least.
>
>>> Also, from the other mail:
>>>
>>>> Shouldn't evaluateScript return a QString, ie the result of the
>>>> evalutation? If I'm not mistaken, ns plugins really depend on the
>>>> string outcome of js script evaluation.
>>>
>>> Well, NPN_Evaluate is supposed to return typesafe values. Perhaps we
>>> should add a toString function to the interface to permit both uses?
>>
>> Hmm, QVariant should be find. I was merely looking at
>> ../khtml/ecma/kjs_scriptable.cpp:849
>>
>> return scriptableNull();
>>
>> which looks like it always returns a null object, no? (Yep there is a
>> TODO above it :)
>
> Erm. Right. The reason I could get away with this is because the old API
> didn't return the value either, so nspluginviewer uses this evil
> eval(this._npresult = eval()) hack with some nasty escaping. Will fix once
> we can agree on the most sensible API scheme.

Yes the old 'partEvent' was overly general thought of, only used for eval().


> Coincindentally, formula1.com is one website to test this stuff on -- it
> doesn't work right w/o some calls from flash to the page, and it does it
> somewhat non-trivially (and on it all the escaping mess with quotes blows
> up)

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 can however get a QDBusArgument out of the variant and do a
manual extraction.
Also serializing Null and Undefined gives an error, Qt doesn't like
the empty struct ("()" signature)
Will see if I get this working, for 'get' I can work around it, but
for arguments for calls from the plugin, I really need an array of
variants.

Koos