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.
2. The location of an icon like a favicon.ico file or png etc.
3. URI to a help page where the site explains how it makes uses of
registerProtocolHandler and gives help and support contacts etc.
4. Whether to use "POST" instead of GET.
For #1, if the UA knows this, it can automatically make sure the data goes
out to the server in the right encoding.
For #2, if the UA knows this, it can automatically provide the desired
icon in its UI next to each entry in its protocol configuration dialog,
for example.
For #3, if the UA knows this, it can automatically provide a site support
link in its configuration dialog.
For #4, if the site would rather (or can only) accept POST data (to
support longer data for example), then the UA can automatically oblige.
With that said, it'd be great if registerProtocolHandler supported a 4th
argument that was an object of informative things.
For example, here are some things that could be supported:
var info = {
"accept-charset" : "koi8-r",
"icon" : "http://example.org/some_dir/favicon.ico";,
"help" : "http://example.org/support/protocol_handling.html";,
"requestMethod" : "POST"
};
navigator.registerProtocolHandler("protocol",
"http://example.org/?uri=%s";, "title", info);
Or, if you'd rather not use an object and just have more arguments:
navigator.registerProtocolHandler(
"protocol",
"http://example.org/?uri=%s";,
"title",
"koi8-r",
"http://example.org/some_dir/favicon.ico";,
"http://example.org/support/protocol_handling.html";,
"post"
);
Now, if you noticed, I used "automatically" above. This is because I think
it would not be ideal to have a site register itself to handle a protocol
only to have it not work by default and have the user find some page on
the site that tells them how to manually configure options in each browser
just to get things working.
To give an example, Opera supports registering certain webmails with
"mailto". You currently have to edit an ini file to add more than the
default and Opera doesn't support registerProtocolHandler yet, but what
Opera does support is specifying an icon URI that gets used in the UI.
Opera also only supports GET at the moment and only supports emitting
utf-8, but there are a few sites where POST and a different output
encoding are desired by the webmail. For example, mail.ru would rather
have POST being used and they only accepted koi8-r (and Windows-1251 as an
option) up until recently.
With that said, if Opera supported registerProtocolHandler to add a
protocol handler (mailto for example), having the site be able to specify
an icon could be usable by Opera and other UAs.
If Opera ever supports using POST or emitting a different encoding, having
the site say so would help so the user doesn't have to manually find out
and configure all this stuff.
Now, Firefox supports registerProtocolHandler for adding handlers now.
But, you can't configure post/get or icons etc. either. But, if you could,
it'd be great to have the site say what to use. (You also have to use an
about:config override to make handler work on any domain)
Finally, it's unfortunate that registerProtocolHandler can't optionally
support a custom format string for the second argument and a format
argument that's a function that gets the URI the user clicked on passed to
it. It's also unfortunate that it's so domain restricted. That's a good
default, but you can see that Firefox has an override for a reason.
For example, all of these webmails don't support what
registerProtocolHandler emits. They only support individual values, which
are different for each webmail.
"http://mymail.operamail.com/scripts/mail/Outblaze.mail?compose=1&did=1&a=1&to=&subject=&body=&cc=&bcc=";
"http://mail.live.com/mail/EditMessageLight.aspx?n=&to=&cc=&bcc=&subject=&body=";
"http://compose.mail.yahoo.com/?To=&Subj=&Cc=&Bcc=&Body=";
"http://your_squirrelmail_server.com/src/compose.php?send_to=&subject=&body=&send_to_cc=&send_to_bcc=";
"http://your_horde_server.com/horde/imp/compose.php?popup=0&to=&cc=&msg=&subject=&bcc=";
"http://mail01.mail.com/scripts/mail/Outblaze.mail?composeto=&subject=&body=&cc=&bcc=&compose=1";
"http://win.mail.ru/cgi-bin/sentmsg?To=&CC=&BCC=&Subject=&BodyUTF8=&accel=1";
"http://your_roundcubemail_server/?_task=mail&_action=compose&_to=&_subject=&_body=&_cc=&_bcc=";
In these cases, the URI format string in registerProtocolHandler would
need a %key for to, subject, body, cc and bcc. The site could use %t, %j,
%k and %l and %m for these for example. But, for the UA to understand
those %keys (since the UA would only understands %s), a custom function
would be needed that did the processing on the link the user clicked and
returned the URI argument with the %keys replaced with the desired values.
So, what this means is that registerProtocolHandler is currently
insufficient for a lot of webmails and will cause the webmails to have to
change processing and do more processing on the server to support it
(instead of just percent-decoding some values, they'll now have to
percent-decode a whole URI, parse it and then percent-decode the
individual values gotten). I believe this will make adoption of
registerProtocolHandler way slower.
Further, for webmails that decide to never support what
registerProtocolHandler emits in any way, it'd be nice if a user could
insert a script (from a community wiki that provides it for example) that
uses registerProtocolHandler with a custom format function that allows
things to be automatically set up for that webmail anyway into the site's
page.
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.
--
Michael
