RFC --- new scripting extension sketches.

[koos vriezen]

2010/5/18 koos vriezen <koos.vriezen at gmail.com>:
> 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.

Actually forget all this nonsense.
Do what is most optimal for khtml, since all calls in the ns plugin
goes through the scriptableextension and needs some rewriting before
putting it on the dbus.
Maybe some extra docu in the .h file would be helpful.


> I am now working to get at least the window.location.href sequence

Works here now.
My plan is to use the NpObject pointer as objId's, On the np side, the
owner field determines whether its a foreign object, wrapped in a
BrowserObject NpObject sub class, or native type where the owner is
set to 0.
I only need one table for all foreign wrapped objects as it looks now.
The scriptableextension should thus rewrite the objects owner field in
case its 0 to this and this to 0.

Koos