[webkit-dev] Does any port implements Navigator.registerProtocolHandler and Navigator.registerContentHandler?

[Gustavo Sverzut Barbieri]

Sorry to disturb this already dead thread, but we're (webkit-efl)
thinking of letting applications/browsers register new protocol
handlers to provide contents themselves. A co-worker, Flávio Ceolin,
will send more details in another thread, but do you have any idea on
the path to have them generically in WebCore?

IMO, the logics would require the network backend to delegate to
WebCoreSupport the unsupported KURL before failing, that could return
some instance to handle the job. This class/instance to handle the job
is not abstracted right now, but could be done in a way that we could
use it in soup/curl (webkit-efl supported backends) and also in qt.

For instance, Qt always delegate access using QNetworkAccessManager
and can do what we said, but it is port-specific. As we have 2 network
backends (we will likely remain with curl later), having a generic
alternative is better, but we could just reuse our code in both
backends.


Any help is appreciated. Regards!


On Thu, Jul 8, 2010 at 3:27 PM, Dmitry Titov <dimich at chromium.org> wrote:
> Thanks to all,
> the bug is here: https://bugs.webkit.org/show_bug.cgi?id=41878
> I've added link to tracking Chromium bug as well.
> Dmitry
>
>
> On Wed, Jul 7, 2010 at 7:59 PM, Jeremy Orlow <jorlow at chromium.org> wrote:
>>
>> That would be the standard thing to do.
>> The sooner someone gets started on the feature, the easier it'll be to
>> revert the patch that removes the code.  :-)
>> J
>>
>> On Thu, Jul 8, 2010 at 10:55 AM, David Levin <levin at chromium.org> wrote:
>>>
>>>
>>> On Wed, Jul 7, 2010 at 5:24 PM, Peter Kasting <pkasting at google.com>
>>> wrote:
>>>>
>>>> On Wed, Jul 7, 2010 at 5:00 PM, Dmitry Titov <dimich at chromium.org>
>>>> wrote:
>>>>>
>>>>> I'd lean to the removal, unless there is a port that has work ongoing
>>>>> or planned soon for those implementations.
>>>>> Does anybody vote for #ifdefs?
>>>>
>>>> I vote against removal if only because Chromium has really wanted these
>>>> badly for a long time and simply hasn't been able to find someone to
>>>> implement them.  Perhaps I could make it worth your while to implement
>>>> rather than remove the stubs?  :)
>>>
>>> Even if someone to implement them for chromium, it doesn't seem to fix
>>> the overall problem. Dmitry indicated that the presences of these is
>>> breaking feature detection in browsers using WebKit (-- which is something
>>> being heard from web developers).
>>> A simple solution is to remove them. Later, any port (including chromium)
>>> who gets someone to work on them could re-add these methods back properly
>>> under ifdef's.
>>> dave
>>> _______________________________________________
>>> webkit-dev mailing list
>>> webkit-dev at lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>
>>
>>
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>



-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbieri at gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202