Den onsdag 11 mars 2015 kl. 20:02:45 UTC+1 skrev Andrew Sutherland: > 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
As the editor of the W3C TCP and UDP Socket API draft, http://www.w3.org/2012/sysapps/tcp-udp-sockets/, I just would like to state that Google has been very active in the adaption of this API to the WHAT WG Streams API specificastion, https://github.com/whatwg/streams/issues/64. However, I can of course not say anything on their interest in actually implementing the API. The main issue is of course the security. This started as a W3C SysApps API, assuming a secure web sys apps environment, but as this thread is discussing we are now moving towards a more open web model with server hosted, uninstalled, web apps. To get further on this API I have defined "permission methods", inspired by the W3C Push API, but the way permission is given is not defined and is dependent on the type of web execution environment. Signed Manifest, https: and CSP are probably part of a solution for this kind of sensitive API. Furthermore, Sony Mobile has been experimentng with "Trusted Hosted Web Apps" for FFOS, https://lists.w3.org/Archives/Public/public-sysapps/2014Sep/att-0000/SoMC_FFOS_Trusted_Hosted_Apps.pdf and https://bugzilla.mozilla.org/show_bug.cgi?id=1016421. Finally I would like to say that I support the ideas that Jonas expresses in his mail starting this discussion and it would be interesting to hear more tangible views on how this could be taken further, e.g. in WHAT WG and W3C. _______________________________________________ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
