Comments below:
----- Original Message -----
> From: "Mounir Lamouri" <[email protected]>
> To: [email protected]
> Cc: "Marcos Caceres" <[email protected]>, "Jonas Sicking" <[email protected]>
> Sent: Tuesday, July 30, 2013 6:07:15 AM
> Subject: Should we deprecate some Firefox OS APIs? (was: Re: Versioning
> system for manifest, Re: Migrating to W3C
> format, was Re: Icon sizes and display densities)
>
> 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.
>
> 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 this is the crux of it, and I agree that we have an opportunity to
introduce a mechanism to promote iteration, experimentation and improvement of
early apis.
What is more controversial is how to achieve this. I think versioning of the
runtime is well worth thinking through. Perhaps we need additional mechanisms
as well to better communicate the maturity of a given api to app developers. I
know we've prefixed new/unstable apis in the past but another possibility in
very early stage apis would be to have something like Chrome Apps have, where
there is an explicit 'experimental' permission that the app has to list in it's
permissions field in the manifest in order to access any experimental apis
(with or without the need to also toggle a flag in the browser/runtime),
further emphasizing the maturity of a given api to the app developer.
-Travis
> 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.
>
> 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.
>
> Cheers,
> --
> Mounir
>
> On 26/07/13 18:07, Marcos Caceres wrote:
> > On Thursday, July 25, 2013 at 3:00 PM, Mounir Lamouri wrote:
> >
> >> On 18/07/13 18:44, Marcos Caceres wrote:
> >>> On Thursday, July 18, 2013 at 6:05 PM, Mounir Lamouri wrote:
> >>
> >> The idea of a manifest version isn't Web-y, indeed; we want to use that
> >> so we can deprecate APIs, this is not at all something we do on the Web.
> >>
> >
> > I would strongly urge us to keep those two concerns separate - a manifest
> > version should be to deprecate manifest things (e.g., if we move to
> > support HD icons) - but should have no relationship to APIs. I.e., treat
> > them as completely orthogonal.
> >
> > In addition, we should only introduce manifest versioning when the time is
> > right and when we have no other option.
> >
> > I discuss API deprecation below. However, I see the Web not following a
> > traditional software development model (i.e., it's versionless) as one of
> > its core strengths as a platform - but that's my ideological position (did
> > I spend too much time at the TAG?:)). I worry when I see us take Web
> > technologies and start bolting on traditional software development
> > paradigms onto them.
> >> However, to take the example I pointed, if, as a developer, I say that
> >> my application requires the version 3.0 and a user wants to install my
> >> application but its device only knows the version 2.0 and earlier, what
> >> should we do?
> >>
> >
> > On the Web, it is assumed that developers would use graceful degradation
> > techniques in such situations. I tend to trust developers want to do the
> > right thing by their users - but I could be wrong. The data that I have on
> > this is the use of modernizr using the WebDevData archive.
> >
> > Running:
> > for b in */*.txt; do ( grep -lm 1 "modernizr" $b ); done | wc -l
> >
> > Of 106,600 documents searched (representing the front page of a site),
> > yields 2401 sites using modernizr: ~2.25%
> >
> > That's at least indicative that quite a few developers care enough to
> > include a library designed to deal with the above.
> >> We can't simply ignore the hint that the app might not
> >> work. A solution could be to simply forbid installation but we can be
> >> smarter about it and do like in AMO where the installation isn't allowed
> >> unless the user check something that says "I want to try anyway".
> >>
> >
> > Sure. But like I said above, this is nothing new on the Web. We've being
> > doing graceful degradation/progressive enhancements since at least 2003
> > [1]. Turned out IE stagnating the Web (and continuing to do so with
> > IE7,8,9) taught developers a thing or two about this! :)
> >> This could indeed be used to evil goals but I am not sure what we can do
> >> to prevent that. If we want to prevent any on purpose fragmentation
> >> based on this feature, the only solution is to assume that all APIs will
> >> stay for ever and the manifest_version property would not be needed.
> >>
> >
> > If we decouple the APIs and the Manifest, they become orthogonal - as I
> > argued they should be.
> >> Note that when I say that the manifest version is incompatible, I am
> >> mostly worried about the usage of new features, not much about the
> >> manifest format.
> >>
> >
> >
> > Me too. But I'd like for us to deal with API deprecation in other ways - if
> > it turns out that we need to deprecate APIs at all. I don't see us
> > stopping support for all the currently prefixed ones in FxOS. It would be
> > *nice* if we eventually enable the W3C ones that do the same thing, but
> > that doesn't require versioning - that only requires simple JS feature
> > detection: if("whatever" in window){ rockAndRoll();}.
> >
> >>>> Should we have a special token like "w3c" or "standard" that will be
> >>>> required to use the standard manifest version? I think that would be
> >>>> reasonable even though that means that if some applications were using
> >>>> "w3c" as a value, it might break them :(
> >>>>
> >>>
> >>> I would like to treat the formats as completely separate (we have
> >>> different ways of installing these manifests as well as different MIME
> >>> types, which serves as the differentiator). Any overlap between the two
> >>> should be seen as coincidental - otherwise, things are going to get
> >>> really messy.
> >>>
> >>
> >>
> >> I am not a big fan of having a fuzzy plan.
> > Neither am I - this is no fuzzy plan - this is drawing a line in the sand
> > here and we have the key bits in place already.
> >> I think we should have
> >> something more defined. What is the current MIME Type Chrome Apps and
> >> Firefox OS apps require?
> >>
> >
> > FxOS doesn't require a mime type, last I checked (we only pay lip service
> > to it).
> >
> > FxOS is: application/x-web-app-manifest+json (not used)
> >
> > Chrome doesn't seem to have one (at least, I could not find it), it's just
> > JSON: thus, probably, application/json (and probably works with none).
> >> What would be the W3C MIME Type?
> >>
> >
> > W3C is: webapp-manifest+json
> >
> >
> > See: http://manifest.sysapps.org/#media-type
> >
> > However, it will also not require that document be served with a MIME type,
> > as the presence of a MIME type cannot be relied on: too few developers
> > have the ability to set such things on their servers so it's pointless to
> > expect it (though we will still recommend it, as they can be somewhat
> > useful in certain situations… maybe, sometimes).
> >> Can we really
> >> assume that developers will simply expose their manifest using another
> >> MIME Type?
> >>
> >
> > That's not necessary. We have two completely distinct ways of handling
> > installation of applications.
> >
> > FirefoxOS uses `navigator.mozApps.install()`
> >
> > The W3C spec uses:
> > <link rel="manifest" href="awesome.webapp">
> >
> >
> > See: http://manifest.sysapps.org/#linking
> >
> > Even if we had an install API for W3C, it would not hang of "moz",
> > obviously, so there is no clash.
> >
> >> Should we consider as a goal to get backward compatibility?
> >>
> >
> > IMO, no. This is too restrictive for FirefoxOS right now.
> >> I am afraid
> >> that new comers will have to implement a mix of Mozilla's and Google's
> >> proprietary formats.
> >>
> >
> > Not if there is a W3C spec that's of quality and has actual implementers
> > behind it.
> >> Also, what should we do if we don't expose a
> >> manifest_version specific to the standard format and a new comer
> >> implements the spec but the manifest is using manifest_version='x' which
> >> would be ignored by the implementation but the manifest would be
> >> half-working.
> >>
> >
> > I must be missing something, but the only way that could happen is if
> > someone tries to pass off a Mozilla or Chrome or even a Commons.js
> > manifest as a W3C one. As silly as that is, the fact that it would "half
> > work" would actually be a feature of the robustness of the W3C manifest
> > parser - but it's only coincidental that they share properties (and that
> > they are JSON).
> >
> > Think of this as being akin the the HTML5 parser - you can throw any
> > garbage at it and it will still give you a DOM.
> >> A solution is indeed to change the MIME Type but then we
> >> have another backward compatibility issue.
> >>
> >
> > MIME types are not useful in practice, so it's best to not even consider
> > them as a solution in our discussions.
> >
> > [1] http://en.wikipedia.org/wiki/Progressive_enhancement
> >
> > _______________________________________________
> > dev-webapps mailing list
> > [email protected]
> > https://lists.mozilla.org/listinfo/dev-webapps
> >
>
> _______________________________________________
> dev-webapps mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-webapps
>
_______________________________________________
dev-webapps mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-webapps
