On Wed, Mar 11, 2015 at 12:01 PM, Andrew Sutherland <[email protected]> wrote: > On Wed, Mar 11, 2015, at 01:58 PM, Jonas Sicking wrote: >> I'm not sure what you're point is then? If only mozilla implements the >> "standard" then it's still not really a standard. Even if it has a W3C >> logo on it. > > I'm not sure I have a point anymore. In this most recent reply I just > wanted to answer your question. > > Making this thread useful, I guess I have a few questions because > although I probably should know these answers, I do not: > > 1) Is there an easy way to tell what Mozilla's stance on a > potential/proposed standard is? Chromium has > https://www.chromestatus.com/features and it seems quite useful since it > makes it clear who the owner is, what someone in the know thinks the > other browsers' interest/plans are, and links to bugs/standards, etc. > It seems like https://bugzil.la/1055074 might be the bug on Mozila > having something like that.
To my knowledge this does not exist. But I agree that it'd be great if it did. I know that it's been talked about, but I don't know that anything has happened beyond that. This would probably fall on jst's and dougt's teams. > I do see a couple resources in our docs: > * https://wiki.mozilla.org/WebAPI/ExposureGuidelines seems to suggest > that searching dev-platform for intent to implement emails works once > we've crossed a certain threshold. This is true. > * Our specific API pages seem potentially misleading in their reference > of standards but without clarification of our intent: > ** > https://developer.mozilla.org/en-US/docs/Web/API/TCP_Socket_API#Standard > links to the TCPSocket spec-work > ** so does https://wiki.mozilla.org/WebAPI > * https://wiki.mozilla.org/WebAPI/PlannedWork has some stuff but it > hasn't been meaningfully updated in exactly 6 months. > > I suspect right now I should be just asking you or :ehsan or :overholt? Yes, for the specific tcp-socket API I think that's true. > NB: I do get that what's happening now is you're proposing a change in > our behaviour related to all of this. Only with regards to "sensitive APIs". But that's a small minority of the APIs that we support. > 2) Is there an easy way to tell whether standardization efforts are > actually going to go anywhere? Like a list of implementers who are > tentatively planning to implement? From looking at raw sockets, that > fact that none of the editors are browser implementers and there hasn't > been much recent activity on the lists certainly makes some > implications. No, there's no such thing. >> So my point that if we're not interested in implementing chrome API, >> then why should Google be interested in implementing one that only we >> support. With or without a W3C logo on it? > > I do think it makes sense to converge to the Google Chrome API if we > make any changes to our implementation given that: > * it seems that the W3C effort is unlikely to yield an implemented > standard, merely a proposed spec > * we're explicitly recognizing this is something that can never be > exposed to the web directly and given that no one else cares about a > spec for this or a lot of other things, it's clear we end up in a custom > runtime environment no matter what, and then it's just a question of > minimizing pain/hassle for developers > * sufficiently capable stream APIs can be wrapped to look like anything > you want > * the Google Chrome developers seem to take the stability/deprecation of > their extension API seriously (noting caveat below) I agree with all of the above. What's less clear to me is what benefits we'd get in practice from implementing the chrome API. > I'm not sure what to do about the "chrome.sockets.tcp" namespace or how > to deal with the potential future API changes of what is explicitly an > extension API for a single evergreen browser. Their APIs do change. > The previous chrome.socket API https://developer.chrome.com/apps/socket > was apparently introduced in Chrome 24, added new multicast methods in > Chrome 28, was superseded by chrome.sockets.tcp > https://developer.chrome.com/apps/sockets_tcp in Chrome 33, and added > support for socket upgrade to SSL/TLS in Chrome 38. (There does not > appear to be away to request that the socket be upgraded to TLS until > connected.) These all seem like sane changes and the refactor > intentional, so I don't think I'd assume the trend would continue > forever, but I also don't think it means we can assume the API will now > be forever stable. Makes sense. Though this would indeed be a quite big problem since we couldn't update our API at the same rate without requiring authors to start supporting multiple versions. / Jonas _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
