On Fri, Jun 22, 2012 at 6:58 AM, Doug Turner <doug.tur...@gmail.com> wrote:
> Is this something that you have discussed at the W3C? Or is this just a moz-specific API, and if so, maybe we should namespace the api until there is some other UA wanting to implement.
Even though this will start out as a single-vendor API, I think it's
better to ship it without a prefix than to use a moz prefix. If we
believe that this APIs good enough to be adopted by others, I think we
should make the naming bet accordingly. I think there's better chance
of this becoming a multi-vendor API if the next vendor who implements
the API can get interop right away without an prefix incompatibility
mess and subsequent unprefixing mess. (If the W3C ends up
standardizing something different, they can pick a different
identifier, e.g. navigator.identity.)
I suggest the following adjustment: If we ship (as in shipping is a
given due to e.g. K9O) an API that no one else implements even
experimentally and we expect the API to be used in Web content
(including installable app; evangelizing the API de facto means we
expect it to be used), we should ship the API unprefixed even if no
one else has an implementation yet and we should propose the API for
standardization. (Ideally, APIs that are targeted for Web content
probably shouldn't be exposed to Web content, though I gather there
may be APIs that only Gaia-bundled apps are expected to call, but
those apps are technically installed Web apps.)
OTOH, if we aren't confident enough in an API to make the bet that the
API could be what ends up being a multi-vendor API, we probably
shouldn't ship the API for use by Web content at all in order to avoid
the grief of apps having to migrate to another API later. In
particular, shipping a prefixed API and then removing the prefixed
version of the API in a subsequent release of Gecko would be bad,
because it would break apps written by the very people who buy into
using our APIs now. On the other hand, I believe e.g. globalStorage
would not have been any less painful if it had been prefixed.
On Friday, June 22, 2012 11:21:05 AM UTC-7, Henri Sivonen wrote:
> For reasons stated in http://hsivonen.iki.fi/vendor-prefixes/ I think
> we should adopt the policy dbaron proposed (
> https://groups.google.com/forum/?fromgroups#!topic/mozilla.dev.platfo... > ) for CSS for Web-exposed APIs as well with an adjustment to cover the
> case of shipping unprefixed APIs without blocking Basecamp or
> Kilimanjaro. (I expect a proposal that'd involve blocking K9O until
> someone else implements to be untenable.)
> I suggest the following adjustment: If we ship (as in shipping is a
> given due to e.g. K9O) an API that no one else implements even
> experimentally and we expect the API to be used in Web content
> (including installable app; evangelizing the API de facto means we
> expect it to be used), we should ship the API unprefixed even if no
> one else has an implementation yet and we should propose the API for
> standardization. (Ideally, APIs that are targeted for Web content
> probably shouldn't be exposed to Web content, though I gather there
> may be APIs that only Gaia-bundled apps are expected to call, but
> those apps are technically installed Web apps.)
> OTOH, if we aren't confident enough in an API to make the bet that the
> API could be what ends up being a multi-vendor API, we probably
> shouldn't ship the API for use by Web content at all in order to avoid
> the grief of apps having to migrate to another API later. In
> particular, shipping a prefixed API and then removing the prefixed
> version of the API in a subsequent release of Gecko would be bad,
> because it would break apps written by the very people who buy into
> using our APIs now. On the other hand, I believe e.g. globalStorage
> would not have been any less painful if it had been prefixed.
I concur in the judgment and the reasoning. SpiderMonkey has been converging on a similar practice: don't prefix, and if it's deemed not solid enough to put into the world and promise to support, disable before beta.
On Friday, June 22, 2012 11:21:05 AM UTC-7, Henri Sivonen wrote:
> For reasons stated in http://hsivonen.iki.fi/vendor-prefixes/ I think
> we should adopt the policy dbaron proposed (
> https://groups.google.com/forum/?fromgroups#!topic/mozilla.dev.platfo... > ) for CSS for Web-exposed APIs as well with an adjustment to cover the
> case of shipping unprefixed APIs without blocking Basecamp or
> Kilimanjaro. (I expect a proposal that'd involve blocking K9O until
> someone else implements to be untenable.)
> I suggest the following adjustment: If we ship (as in shipping is a
> given due to e.g. K9O) an API that no one else implements even
> experimentally and we expect the API to be used in Web content
> (including installable app; evangelizing the API de facto means we
> expect it to be used), we should ship the API unprefixed even if no
> one else has an implementation yet and we should propose the API for
> standardization. (Ideally, APIs that are targeted for Web content
> probably shouldn't be exposed to Web content, though I gather there
> may be APIs that only Gaia-bundled apps are expected to call, but
> those apps are technically installed Web apps.)
> OTOH, if we aren't confident enough in an API to make the bet that the
> API could be what ends up being a multi-vendor API, we probably
> shouldn't ship the API for use by Web content at all in order to avoid
> the grief of apps having to migrate to another API later. In
> particular, shipping a prefixed API and then removing the prefixed
> version of the API in a subsequent release of Gecko would be bad,
> because it would break apps written by the very people who buy into
> using our APIs now. On the other hand, I believe e.g. globalStorage
> would not have been any less painful if it had been prefixed.
I concur in the judgment and the reasoning. SpiderMonkey has been converging on a similar practice: don't prefix, and if it's deemed not solid enough to put into the world and promise to support, disable before beta.
