Is anyone using data from ChromeHangs?
In bug 1448040 I'm looking at consolidating / cleaning up / removing hang monitoring threads, and the question came up whether we could just get rid of the thread that reports chromeHangs[1]. I didn't want to step on anyone's toes though, so if you use this or know someone who does then please let me know. [1]: https://searchfox.org/mozilla-central/rev/68fdb6cf4f40bea1a1f6c07531ebf58fb8ab060b/xpcom/threads/HangMonitor.cpp#193 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: JSON-LD Working Group
On Fri, Apr 27, 2018 at 2:09 PM, Adam Roach wrote: > On 4/27/18 2:02 PM, L. David Baron wrote: >> >> On Friday 2018-04-27 10:07 +0300, Henri Sivonen wrote: >>> >>> For this reason, I think we should resist introducing dependencies on >>> JSON-LD in formats and APIs that are relevant to the Web Platform. Agreed with Henri summary criticism and have been warning as much (re: introducing dependencies on JSON-LD) for a few years. The specific concern to call out in the charter is only implied by the Coordination section: https://www.w3.org/2018/03/jsonld-wg-charter.html#w3c-coordination In particular we could state some concern about these which will likely impact our (Mozilla) products: "* Web of Things Working Group" (though I am unsure if "that ship has sailed" or not - that is, I have not dug deep enough to determine if WoT work is actively dependent on JSON-LD, heading that way, or not at all yet) " * Publishing Working Group The Publishing Working Group is considering using JSON-LD as a serialization format for various types of metadata for Web Publications, as well as a serialization format for the Web Publication Manifest. " Nevermind a separate Web Publication Manifest from Web App Manifest (which itself is an issue, cc Marcos), it is likely that Firefox will end up having to support whatever Web Publication format(s) come out of W3C, thus we should be actively advocating for something that does not need JSON-LD. >>> I >>> think it follows that we should not support this charter. I expect >>> this charter to pass in any case, so I'm not sure us saying something >>> changes anything, At a minimum we should explicitly Abstain in our review, with comments. The other reasonable option is a non-formal objection. >>> but it might still be worth a try to register >>> displeasure about the prospect of JSON-LD coming into contact with >>> stuff that Web engines or people who make Web apps or sites need to >>> deal with Yes we should register our displeasure, and it is not just a "prospect", there are (problem) examples already, most notably due to Google Search side latest syntax du jour for serp rich snippets being JSON-LD data islands in HTML. The stats for JSON-LD adoption are essentially all publishing, primarily for Google Search's opaque consumption. * SEO types putting JSON-LD into HTML documents, with no way to verify any actual processing impact / results (validators exist to check syntax, but not show impact on actual results to users). Aside: Google Search has cycled through recommending Google Base, GData XML, microformats, RDFa, microdata, JSON-LD all in the past, without technical reasons or evidence and yet still supports most of what they supported in the past: https://aaronparecki.com/2016/12/17/8/owning-my-reviews#historical-recommendations There is no actual "need" for JSON-LD in practice for the Google/Search SEO "use-case". >>> and to register displeasure with designing formats whose >>> full processing model differs from how the format is evangelized to >>> developers (previously: serving XHTML as text/html while pretending to >>> get benefits of the XML processing model that way). This is a very good way of communicating the problem. The dual message of: * You can treat it just as a subset of JSON * If you want extra features if you have to parse it as JSON-LD Has had problems with such extra features in practice, especially in any ecosystem attempting to evolve extensions (supposedly one benefit of JSON-LD) across implementations, with forward/backward compatibility etc. (Do you update the @context file in-place or use a new @context? When do you update? What about implementations that include @context information "at compile time" Etc.) >> Yeah, I'm not quite sure how to register such displeasure. In >> particular, I think it's probably poor form to object to maintenance >> work on a base specification, even if we're opposed to that >> specification's use elsewhere. At least, assuming we don't want to >> make the argument that the energy being spent on that maintenance >> shouldn't be. On the flip side, from what I've seen, non-trivial maintenance and extensibility issues have been found with JSON-LD due to implementation feedback and iteration. In as much as there's a group of folks willing to do this maintenance, it seems prudent to let them do so, presuming the cost to W3C staff is minimal (I saw 0.1 but am not sure if I believe that). >> I'm inclined to leave this one alone, unless somebody else comes up >> with a better position we could take. I think we should register an explicit Abstain, and state our concerns that Henri summarized, our "displeasure about the prospect of JSON-LD coming into contact with stuff that Web engines or people who make Web apps or sites need to deal with", and make that public. Things we could object to: * Seemingly open ended "new features" as referred to in the charter. The charter refers to "requests for new fe
Re: Proposed W3C Charter: JSON-LD Working Group
On Friday 2018-04-27 16:09 -0500, Adam Roach wrote: > If there's a set of behaviors defined by the 1.0 spec, and a different set > of behaviors implemented, deployed, and evangelized, I think it would be > reasonable to object (on that basis) to a charter that does not explicitly > include work items to bring the spec into line with reality. I think the issue is that *some* of the users of the specification are doing this. I think we should strongly object to specifications that use it that way... but I still find it hard to formulate an objection to JSON-LD itself. (Especially for relatively small maintenance to the spec.) I think an analogy to what's happening would be to specs claiming to use XML namespaces, but some of them relying on the tag being "html:select" rather than doing processing of the xmlns attributes to figure out what the "html:" (or "xhtml:", etc.) prefix means. Except that in this case it's a more complicated thing than XML namespaces: the full RDF data model. -David -- π L. David Baron http://dbaron.org/ π π’ Mozilla https://www.mozilla.org/ π Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: PGP signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: JSON-LD Working Group
On 4/27/18 2:02 PM, L. David Baron wrote: On Friday 2018-04-27 10:07 +0300, Henri Sivonen wrote: For this reason, I think we should resist introducing dependencies on JSON-LD in formats and APIs that are relevant to the Web Platform. I think it follows that we should not support this charter. I expect this charter to pass in any case, so I'm not sure us saying something changes anything, but it might still be worth a try to register displeasure about the prospect of JSON-LD coming into contact with stuff that Web engines or people who make Web apps or sites need to deal with and to register displeasure with designing formats whose full processing model differs from how the format is evangelized to developers (previously: serving XHTML as text/html while pretending to get benefits of the XML processing model that way). Yeah, I'm not quite sure how to register such displeasure. In particular, I think it's probably poor form to object to maintenance work on a base specification, even if we're opposed to that specification's use elsewhere. At least, assuming we don't want to make the argument that the energy being spent on that maintenance shouldn't be. I'm inclined to leave this one alone, unless somebody else comes up with a better position we could take. With the caveat that I have very limited knowledge about JSON-LD and am basing this mostly on the preceding exchange: If there's a set of behaviors defined by the 1.0 spec, and a different set of behaviors implemented, deployed, and evangelized, I think it would be reasonable to object (on that basis) to a charter that does not explicitly include work items to bring the spec into line with reality. /a ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: JSON-LD Working Group
On Friday 2018-04-27 10:07 +0300, Henri Sivonen wrote: > For this reason, I think we should resist introducing dependencies on > JSON-LD in formats and APIs that are relevant to the Web Platform. I > think it follows that we should not support this charter. I expect > this charter to pass in any case, so I'm not sure us saying something > changes anything, but it might still be worth a try to register > displeasure about the prospect of JSON-LD coming into contact with > stuff that Web engines or people who make Web apps or sites need to > deal with and to register displeasure with designing formats whose > full processing model differs from how the format is evangelized to > developers (previously: serving XHTML as text/html while pretending to > get benefits of the XML processing model that way). Yeah, I'm not quite sure how to register such displeasure. In particular, I think it's probably poor form to object to maintenance work on a base specification, even if we're opposed to that specification's use elsewhere. At least, assuming we don't want to make the argument that the energy being spent on that maintenance shouldn't be. I'm inclined to leave this one alone, unless somebody else comes up with a better position we could take. -David -- π L. David Baron http://dbaron.org/ π π’ Mozilla https://www.mozilla.org/ π Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: PGP signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: new helper class for MozPromise in DOM code
On Fri, Apr 27, 2018, 3:13 AM Jean-Yves Avenard wrote: > > The class is called DOMMozPromiseRequestHolder. Here is an example using > > it: > > is that just a refcounted version of MozPromiseRequestHolder? > No. It binds to the global and calls DisconnectIfExists() when the global invokes DisconnectFromOwner() on it. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: new helper class for MozPromise in DOM code
Hi > On 26 Apr 2018, at 10:12 pm, Ben Kelly wrote: > > Hi all, > > I pushed a new helper class to inbound today to make it easier to work with > MozPromise in DOM code. Specifically, it allows you to auto-disconnect a > Thenable request when the global dies. > > The class is called DOMMozPromiseRequestHolder. Here is an example using > it: is that just a refcounted version of MozPromiseRequestHolder? smime.p7s Description: S/MIME cryptographic signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: JSON-LD Working Group
On Fri, Apr 27, 2018 at 1:04 AM, L. David Baron wrote: > The W3C is proposing a charter for: > > JSON-LD Working Group > https://www.w3.org/2018/03/jsonld-wg-charter.html > https://lists.w3.org/Archives/Public/public-new-work/2018Mar/0004.html > > Mozilla has the opportunity to send comments or objections through > Sunday, April 29. (Sorry for failing to send this out sooner!) > > This is a charter to produce JSON-LD 1.1 (A JSON-based Serialization > for Linked Data), which is a revision of JSON-LD 1.0, which was > developed under the now-closed RDF Working Group. The > specifications proposed in a charter have been developed in a > community group. > > Please reply to this thread if you think there's something we should > say as part of this charter review, or if you think we should > support or oppose it. JSON-LD's compatibility with the RDF data model and the fundamental principle that identifiers expand to URIs means that JSON-LD perpetuates the fundamental ergonomic problem of RDF. All serializations of RDF, JSON-LD included, try to take steps to alleviate the visibility of the problem on the syntax level but none can git rid of the problem on the data model layer (since they subscribe to the fundamental principle that is the source of the problem and don't break data model compatibility). Thus, code that processes the formats either has to be unergonomic or incorrect. It's bad to have specs that promote unergonomic or incorrect implementations and especially the mutually-incompatible co-existence of the two. See https://hsivonen.fi/no-json-ns/ for an elaboration--especially the epilog. JSON-LD evangelism, including the slides linked to from the charter (slide 3), tends to be about selling the format by claiming that developers can ignore the RDF/URI stuff (i.e. write code that's incorrect in terms of the full processing model). The very last section of https://hsivonen.fi/no-json-ns/ addresses this based on experience from Web-scale formats. For this reason, I think we should resist introducing dependencies on JSON-LD in formats and APIs that are relevant to the Web Platform. I think it follows that we should not support this charter. I expect this charter to pass in any case, so I'm not sure us saying something changes anything, but it might still be worth a try to register displeasure about the prospect of JSON-LD coming into contact with stuff that Web engines or people who make Web apps or sites need to deal with and to register displeasure with designing formats whose full processing model differs from how the format is evangelized to developers (previously: serving XHTML as text/html while pretending to get benefits of the XML processing model that way). -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
