- From: Michael A. Puls II <shadow2531@gmail.com>
- Date: Tue, 22 Sep 2009 11:32:59 -0400
On Tue, 22 Sep 2009 09:10:02 -0400, Anne van Kesteren <annevk at opera.com>
wrote:
> On Sat, 19 Sep 2009 13:49:15 +0200, Michael A. Puls II
> <shadow2531 at gmail.com> wrote:
>> Currently, registerProtcolHandler works like this:
>>
>> navigator.registerProtocolHandler("protocol",
>> "http://example.org/?uri=%s", "title");
>>
>> However, this doesn't allow the site to specify some useful and
>> important information about the site like:
>>
>> 1. What encoding the server expects. For example, uri= might expect the
>> protocol link that was invoked in the browser to be interpreted as
>> koi8-r instead of utf-8. This might be the case even if the page that
>> uses registerProtocolHandler uses Windows-1251 for example.
>
> The IRI specification dictates UTF-8 already.
But sites might not follow it.
>> 2. The location of an icon like a favicon.ico file or png etc.
>
> Is this not already known? Or is there no same-origin restriction on
> these methods?
Do you mean, is the location known like favicon.ico at the root of the
site? It's not always in that spot. And, if it's not a favicon, but a png
for example, it could be anywhere on the site.
>> 3. URI to a help page where the site explains how it makes uses of
>> registerProtocolHandler and gives help and support contacts etc.
>
> How does this help the user?
Say the user sees that things are not working right with the handler. The
user goes into the options to see what's doing with the handler settings
and notices the link. The user clicks on it. Then, on the page, it says
"Attention: We've changed some things with what our server accepts from
our protocol handler. You need to register the handler again by clicking
here to get the updated version" for example. User does and is happy
again. :)
Now, the user could go hunting through the site to find that page, but the
link is much more user-friendly.
>> 4. Whether to use "POST" instead of GET.
>
> That seems dangerous. Following a link should always use GET.
But, I don't think it's necessarily "following a link" in the normal
sense. It's launching a trusted web-based application, where POST could be
used to support longer data.
Sure, it's great to look at the query to see what's being submitted (if
it's in a format that you know how to decode).
By default though, the handler only works on pages for the site that
registered the handler, so it'd be like just using a form POST right on
the site.
>> [...]
>>
>> Point being, registerProtocolHandler needs to be more robust. And,
>> although this post is long, the requested additions are quite simple to
>> specify.
>>
>> Maybe these things can be supported in registerProtocolHandler v.02
>> once sites like the above prove that they are needed.
>
> I don't see why existing sites would not update what they accept to make
> registerProtocolHandler work.
I do. Sites can be a pain. :)
> And if user agents want to support sites that do not support
> registerProtocolHandler that is their business I think and not an
> necessarily an issue for the feature.
Sure, but if registerProtocolHandler is robust, users don't have to wait
around for browsers to do that. registerProtcolHandler would be
self-sufficient.
I think it's important to have robust tools to allow users to make things
work when either the site or the browser or both are of no help. But, my
main point in all this is if the UA has more than just a plain UI, it
could make use of more info given by registerProtocolHandler to make
things nicer.
In short though, I think registerProtocolHandler is too simple. Maybe
that's intentional and browses are encouraged to support some other more
advanced function like
window.ff|ie|opera|safari|chrome_advancedRegisterProtocolHandler, but why
do that when registerProtocolHandler could?
But, understood if you don't share my enthusiasm.
--
Michael
Received on Tuesday, 22 September 2009 08:32:59 UTC