Re: [PATCH] Add user content APIs for WebKit Xwidgets

[Qiantan Hong <qthong@stanford.edu>]

>> 1. I think that connecting signal to scriptor (now called manager)
>> doesn't require xw to be marked, because it is also destroyed when xw
>> is killed? Suppose that now I reference count correctly, manager
>> should be owned by xw, just like the WebKitWebContext at line 363.
> 
> No, because webkit_web_view_new_with_related_view is used to create
> WebKitWebView objects when an existing live xwidget is specified as the
> related argument to `make-xwidget', and those will hold further
> references to the content manager beyond the lifetime of the
> WebKitWebView holding the initial reference to said content manager.  In
> fact, won't userscripts apply to every WebKitWebView with the same
> content manager?
> 
> I think I would prefer documenting and implementing userscripts as
> applying to all related xwidgets: you could link each related xwidget
> onto a circular queue, designate one as the "head", and hold a reference
> to the head, replacing it with a different xwidget on the queue each
> time the head is killed, until there are no more xwidgets on that queue,
> at which point it becomes safe to free the userscript data.

Applying to all related Xwidgets sound like a good idea. I think we should
formalize the "group of related Xwidgets" as some kind of object? Maybe
a record type implemented in Lisp, or a pseudo vector (which I don't know
much about how to implement). An alternative is to expose content manager
as a pseudovector, which will in fact have 1-to-1 correspondence with "related
group", but I like related group more because it feels like a nicer abstraction.

What do you think?

If that is implemented I believe we also don't need extra marking, as the
manager will hold a reference to the related group object, but the related
group object will be collected only all related xwdigets are already killed.

Best,
Qiantan