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. 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. * 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? NB: I do get that what's happening now is you're proposing a change in our behaviour related to all of this. 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. > 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'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. Certainly we can try and talk to them about it. One question would be what do we do if they really don't want us imitating their APIs? :) Andrew _______________________________________________ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
