On Tuesday, July 30, 2013 at 2:07 PM, Mounir Lamouri wrote:
> Hi,
>
> I am forking this thread to something else because it seems that we have
> a fundamental disagreement regarding the ability to deprecate some
> Firefox OS APIs.
>
> We added a lot of APIs that we would like to modify or remove recently
> because of the Firefox OS effort - some/many of them being immature. The
> natural way of doing things in the Web would be to simply wait until,
> maybe, some day, those APIs would have a marketshare so low that it
> would not disrupt to simply remove them.
>
> However, most of those APIs were not added to the Web but to some
> extension of it living in packaged/privileged applications. Those
> applications have their content inside a zip file, have a manifest and
> will be only installable via the Firefox Marketplace. This is a very
> different setup than the Web, this is more a technology based on the Web
> Platform than really the Web given that some key features like a
> decentralised system do not exist.
Agreed.
> In a centralised system, it is way simpler to deprecate things and I
> think we should take this opportunity. Not because we want to violate
> the basic rules of the Web but because we should use that situation to
> make packaged applications a playground where we can try APIs without
> being forced to support them forever.
I think that is fine, so long as it does not adversely affect users - i.e., if
we are going to remove/change APIs, we need a nice transitional path for
developers (including actively helping them migrate to the new APIs) and we
need to continue to support the old APIs for a while (till the content relying
on the deprecated stuff is insignificant - channelling a bit of Matt Basta
here: if people paid for a packaged app, that app should hopefully work for the
life of their device).
The question is, what APIs do we want to deprecate? and what would we replace
them with (the W3C ones or new FxOS-based ones)?
> There are not that many APIs created specifically for Firefox OS that
> end up in hosted web applications (on top of my head, I see Screen
> Orientation, mozApp and Alarm API). For those, we should have a
> case-by-case decision regarding their future but I guess the usual Web
> way of doing things should work.
Agreed. BTW, I'm supportive that FxOS gives us a way to iterate ideas that we
can then attempt to standardize.
> I understand that using manifest_version for this would not be the best
> property name. Maybe we should use 'runtime_version'. Though, I now
> wonder if we would need a 'manifest_version' ;)
>
> I would be interested to hear feedback regarding this, especially from
> Marcos who did not look very happy with the idea of having a deprecation
> system.
>
I think we need to consider API transitions on a case by case basis (and then
look at them as a group). If there is a backwards compatible "quick win" way to
extend/deprecate functionality in APIs without needing a versioning scheme, we
should use that (see David Bruant's proposal about DOMRequest extending
Promises)… otherwise, we could group a large change-set and call it
version.next.
Sorry about the rushed email and not having any real solutions here - but I'm
about to vanish on vacation so trying to finish off a million things today:(
Happy to help with this when I'm back!
_______________________________________________
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps
