[Webkit-unassigned] [Bug 125990] [GTK] Allow passing extra initialization data to web extensions

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=125990





--- Comment #7 from Carlos Garcia Campos <cgarcia at igalia.com>  2013-12-20 04:00:34 PST ---
(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > (From update of attachment 219636 [details] [details] [details])
> > > So, what I understand from reading the API and the changelog is we are passing a GVariant with arbitrary initialization parameters for all extensions when we get a signal emission. I have a question and a suggestion:
> > > 
> > > Why do we need the signal for that, is it because of some architectural constraint/implementation difficulty? Can't we just set the data along with the path before the extensions are even loaded?
> > 
> > Being this a signal fixes two problems:
> > 
> >  - It allows you to set dynamic data, in case of multiple web processes you might want to set different data for each web process, like a unique id, for example. We might use that to make sure that the dbus names used by the web extensions are different.
> > 
> >  - It sets a place to initialize the web extensions directory (and this user_data).
> 
> Exactly. IMHO not having to warn in the documentation “do this before
> $FOO happens” is a good thing: having the warning in the docs makes it
> easy for developers to skip it, ot to have to do guesswork when they
> have to decide when to call a certain function. If we provide a signal
> there is an event that clearly points when.
> 
> > > I think it would be better to call this "initialization parameters" instead of extra data, so it's clearer what they are for. I thought at first that they would be something that can be sent at any point rather than just for initialization.
> > 
> > what about initialization_user_data? which is what wk2 uses internally?
> 
> I wasn't sure whether to let the name permeate to the public WebKitGTK API, 
> but it is also true that “extra data“ or ”user data“ lacks clarity... Let's
> go with “initialization user data” then.

After thining about it a bit more, I think I prefer just user_data, at least in the way it's currently implemented. Ideally, this should actually be initialization data, passed as parameter to webkit_web_extension_initialize, instead of getting it from the WebExtension object. That way we wouldn't need to keep the data in memory all the time. The problem is that we can't change the initialization symbol (unless we deprecate the current one and add a new one receiving the initialization user data, not sure it's worth it). The thing is that the way we are currently implementing, it's data associated to the web extension passed by the user from the ui process. You can get that data from the web extension object at any time. So, in my opinion we could:

 a) Deprecate webkit_web_extension_initialize() and add a new symbol receiving the init user data. We would check the new symbol first always falling back to the deprecated one when not found. 

 b) Use just user_data always available from the web extension and avoid the initialization word to avoid confusion. 

I think a) is the ideal solution from the API point of view, but requires to deprecate current init symbol.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.