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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Dec 20 04:17:07 PST 2013


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





--- Comment #9 from Carlos Garcia Campos <cgarcia at igalia.com>  2013-12-20 04:15:09 PST ---
(In reply to comment #8)
> (In reply to comment #6)
> > >  - 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.
> 
> Sounds like this bug should depend no bug 123292 then =)

It's not the same, this happens before the new web process is launched, and the other one is emitted when the web process has been launched and the connection has been established, which is too late to set user data and web extensions dir.

> (In reply to comment #7)
> > 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.
> 
> I think going with a and calling it 'initialization user data' would be the best from an API perspective. We can ditch the data once the extension is initialized - if the extension really wants to keep it they can store it themselves, how about that? We don't really need to deprecate the initialize function, actually, it's kind of a _new() and _new_with_text() kind of thing from my perspective.

It's a bit weird having two entry points, but I don't see any problem. We can add webkit_web_extension_inisitalize_with_user_data() then and document that if this is present the other one is ignored.

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


More information about the webkit-unassigned mailing list