[Webkit-unassigned] [Bug 73638] [EFL] Implement 'registerProtocolHandler' function

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue May 15 19:42:42 PDT 2012


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





--- Comment #33 from Dongwoo Joshua Im (dwim) <dw.im at samsung.com>  2012-05-15 19:41:46 PST ---
(In reply to comment #31)
> First of all, sorry for repeating some comments -- we've been discussing this for so long that I really forgot what I had already said :-)
> 
> (In reply to comment #28)
> > This API works like this.
> >  1. Web app try to register a protocol handler.
> >  2. WebKit pass the information to the application who is using the WebKit at that time.
> >  3. Application save the information into DB or whatever.
> >  4. When the protocol is shown, application redirect the url regarding the information.
> > 
> > So, WebKit only need to pass the right information to the application.
> 
> (In reply to comment #29)
> > > > Source/WebKit/efl/ewk/ewk_custom_handlers.cpp:29
> > > > +    evas_object_smart_callback_call(data->ewkView, "protocolhandler,register", data);
> > > I'm a bit confused about the behavior here -- is the intention of the code at this point to simply notify API users that this has happened or is this actively part of the process of registering a new protocol handler? In case it's the latter, then it probably makes sense to add a virtual function to the Ewk_View_Smart_Class structure and call it instead of emitting a signal.
> 
> > Yes. notify to the application.
> > As I know, that's what WebKit supposed to do all about.
> 
> > > > Source/WebKit/efl/ewk/ewk_view.h:73
> > > > + *  - "protocolhandler,register", Ewk_Custom_Handler_Data: add a handler url for the given protocol.
> > > Nit: we generally use the present perfect form for the verbs in signals ("displayed", "set") instead of the infinitive. After all, this is something that has already happened.
> 
> > Registering a handler will be happened after an application get this signal.
> > I think "register" is right form in this case.
> 
> > But, if it is a coding style of the EFL port, I will changed this  "protocolhandler,registered"
> 
> Let us clear this part up before the others. What I am asking here is whether the application is part of the protocol registration process or if it is simply notified that the registration happened. In your comment #28 and the first block of comment #29 I quoted, you seem to say that it is the latter; in the last block I quoted, you say that the handler registration will only have happened after the application is notified. I am not sure if you mean this from the point of view of the application (it will only know about the whole protocol registration thing going on in WebKit after it catches the signal indeed) or from WebKit's point of view (in which case synchronously calling a function defined in Ewk_View_Smart_Class is a vital part of the registration process, for example because it needs some return value from the application code).
> 
> If the application really simply needs to be notified that this event happened, using "registered" really makes much more sense than "register"; if it's the opposite, you need to change your code and should not be emitting a signal anyway.


Regarding comment #28 I've wrote, 
 * WebKit pass the information to the application who is using the WebKit at that time.
 * Application save the information into DB or whatever.


So, the answer of your question is this.

Q: What I am asking here is whether the application is part of the protocol registration process or if it is simply notified that the registration happened.

A: WebKit simply notify to the application that registration is needed, 
and then, the application register the handler and keep it in itself by DB or whatever.

So, the "actual" action, registering, is happened in the application.
That's why I want to 'register' rather than 'registered' in WebKit.

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