RFC --- new scripting extension sketches.

[Maksim Orlovich]

> 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).

>
> 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.


>> 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.

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)

Thanks,
Maks