Re: Linked Data must die. (was: Linked Data and a new Browser API event)
I'd definitely like to keep the implementation of whatever formats we use in Gaia given that this is still an experimental feature and the use cases are likely to evolve as we get user feedback. It seems to me that given that our use case here, beyond OG, is only our internal content, I.e. Gaia. So effectively we can choose whatever format here we want as it has no effect on web content. Given that, I'd definitely optimize for simplicity and simply extend OG. If we want those extensions to not leak to the rest of the web we can simply make the system app only honor those tags in Gaia content. / Jonas On Mon, Jun 29, 2015 at 2:47 PM, Benjamin Francis bfran...@mozilla.com wrote: Thanks for the responses, Let me reiterate the Product requirements: 1. Support for a syntax and vocabulary already in wide use on the web to allow the creation of cards for the largest possible volume of existing pinnable content 2. Support for a syntax with a large enough and/or extensible vocabulary to allow cards to be created for all the types of pinnable content and associated actions we need in Gaia We need to deliver this by B2G 2.5 FL in September. *Existing Web Content* I think we're agreed that Open Graph gives us enough of a minimum viable product for the first requirement. However, it's not OK to just hard code particular og types into Gecko, we need to be able to experiment with cards for lots of different Open Graph types without having to modify Gecko every time (imagine system app addons with experimental card packs). Open Graph is just meta tags and we already have a mechanism for detecting specific meta tags in Gaia - the metachange event on the Browser API. As a minimum all we need to do to access Open Graph meta tags is to extend this event to include all meta tags with a property attribute, which is only used by Open Graph. We could go a step further and extend the event to all meta tags, which would also give us access to Twitter card markup for example, but that isn't essential. We do not need an RDFa parser for this, we can filter/clean up the data in the system app in Gaia where necessary (the system app is widely regarded to be part of the platform itself). *Gaia Content* Open Graph does not have a large enough vocabulary, or (as Kelly says) the ability to associate actions with content, needed for the second requirement. Schema.org has a large existing vocabulary which basically fulfils these use cases, though some parts are more tested than others, with examples given in Microdata, RDFa and JSON-LD syntaxes, eg: - Contact - http://schema.org/Person - Event - http://schema.org/Event - Photo - http://schema.org/Photograph - Song - http://schema.org/MusicRecording - Video - http://schema.org/VideoObject - Radio station - http://schema.org/RadioChannel - Email - http://schema.org/EmailMessage - Message - http://schema.org/Comment Schema.org also provides existing schemas for actions associated with items (https://schema.org/docs/actions.html), although examples are only given in JSON-LD syntax. Schema.org is just a vocabulary and Tantek tells me it's theoretically possible to express this vocabulary in Microformats syntax too - it's possible to create new vendor prefixed types, or suggest new standard types to be added to the Microformats wiki. This would be required because Microformats does not have a big enough existing vocabulary for Gaia's needs. Microdata, RDFa and JSON-LD use URL namespaces so are extensible by design with a non-centralised vocabulary (this is seen as a strength by some, as a weakness by others). The data we have [1][2][3][4] shows that Microdata, then RDFa (sometimes considered to include Open Graph), is used by the most pinnable content on the web, but the data does not include all modern Microformats. We also don't have any data for JSON-LD usage. However, existing usage is not the most important criteria for the second requirement, it's how well it fits the more complex use cases in Gaia (and how much work it is to implement). There is resistance to implementing a full Microdata or RDFa parser in Gecko due to its complexity. JSON-LD is more self-contained by design (for better or worse) and could be handed over to the Gaia system app directly via the Browser API without any parsing in Gecko. Microformats is possibly less Gecko work to implement than Microdata or RDFa, but more than JSON-LD. *Conclusions* My conclusion is that the least required work in Gecko for the highest return would be: 1. *Open Graph* (bug 1178484) - Extending the existing metachange Browser API event to include all meta tags with a property attribute. This would allow Gaia to add support for all of the Open Graph types, fulfilling requirement 1. 2. *JSON-LD* (bug 1178491) - Adding a linkeddatachange event to the Browser API which is dispatched by Gecko whenever it
Re: Does jpm support for Thunderbird.
2015-07-02 18:19 GMT+08:00 J. Ryan Stinnett jry...@gmail.com: The mozilla-labs-jetpack list and/or #jetpack on IRC are probably better (more focused) places to discuss JPM. - Ryan On Thu, Jul 2, 2015 at 5:14 AM, 罗勇刚(Yonggang Luo) luoyongg...@gmail.com wrote: I am looking for it to developing plugins for thunderbird -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Does jpm support for Thunderbird.
I am looking for it to developing plugins for thunderbird -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: mozilla::TemporaryRef is gone; please use already_AddRefed
On Thu, Jul 2, 2015 at 9:21 AM, Neil n...@parkwaycc.co.uk wrote: Nathan Froyd wrote: I tried this, fixed a few compilation errors, then decided this wasn't worth it just yet and threw my work into a bug. Comments appreciated: https://bugzilla.mozilla.org/show_bug.cgi?id=1179451 1. It's because QueryInterface has to addref, so we can't directly pass the returned pointer. (But otherwise it's effectively the same as 4.) Sure. This also comes up when passing the results of nsCOMPtrT-returning functions to other things, or returning them as raw pointers. This might point to a deficiency in APIs, of course. 2. Ugh, standard MSVC optimisation doesn't compile an nsCOMPtr in a ternary at all well. (If my x86_64 is up to scratch then I think it creates an internal flag so it remembers which arm of the ternary was constructed.) Hooray for forcing people to write the efficient code, then? :) 3. Why isn't the const nsCOMPtrT converting to a T*? (There's too much indirection for my liking, so I can't work out which storage class is getting applied to the argument.) Because for something like: nsCOMPtrnsIRunnable event = NS_NewRunnableMethodWithArgnsCOMPtrnsIDOMHTMLInputElement (this, nsFormFillController::MaybeStartControllingInput, focusedInput); the nsCOMPtrnsIDOMHTMLInputElement gets the storage class StoreCopyPassByValuensCOMPtrT, which means that the argument gets passed as a (copied!) nsCOMPtr. And that's a temporary, so the implicit conversion to T* is disallowed. I guess we could fix this in current m-c to be smarter about the parameter passing, perhaps by declaring that ParameterStoragensCOMPtrT is StoreCopyPassByConstLRefnsCOMPtrT? (Similarly for nsRefPtrT.) If people want something else, they can explicitly ask for it. 4. Maybe I'm confused, but isn't this the pattern we're trying to avoid so that we can remove already_AddRefed and use moves instead? That's a good point, I didn't consider that when just trying to make things compile. In the particular case I remember fixing (calling nsIDocument::GetBaseURI), the result was stored as a T* (!), so we would have had to construct something explicitly anyway. -Nathan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: mozilla::TemporaryRef is gone; please use already_AddRefed
Nathan Froyd wrote: I tried this, fixed a few compilation errors, then decided this wasn't worth it just yet and threw my work into a bug. Comments appreciated: https://bugzilla.mozilla.org/show_bug.cgi?id=1179451 1. It's because QueryInterface has to addref, so we can't directly pass the returned pointer. (But otherwise it's effectively the same as 4.) 2. Ugh, standard MSVC optimisation doesn't compile an nsCOMPtr in a ternary at all well. (If my x86_64 is up to scratch then I think it creates an internal flag so it remembers which arm of the ternary was constructed.) 3. Why isn't the const nsCOMPtrT converting to a T*? (There's too much indirection for my liking, so I can't work out which storage class is getting applied to the argument.) 4. Maybe I'm confused, but isn't this the pattern we're trying to avoid so that we can remove already_AddRefed and use moves instead? -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: mozilla::TemporaryRef is gone; please use already_AddRefed
Jeff Muizelaar wrote: I believe this is predicated on removing the implicit conversion from nsRefPtrT to T* Would you mind reminding me what the failure case this avoids is? -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Linked Data must die. (was: Linked Data and a new Browser API event)
On Thu, Jul 2, 2015 at 4:37 AM, Tantek Çelik tan...@cs.stanford.edu wrote: Schema.org also provides existing schemas for actions associated with items (https://schema.org/docs/actions.html), ... Currently the IndieWeb community is pursuing Web Actions (and has them working across sites) http://indiewebcamp.com/webactions TL;DR WebActions, as presented in [1], are not sufficiently well developed for us to base an implementation upon. With lots of additional work, they could one day form the basis of an implementation, but, as a target for FirefoxOS 2.5, they are simply not there yet. !(TL;DR) I am uneasy about going in too much detail about each point as I feel that doing so will be a waste of my time and yours. So, I'll try to keep it short. The WebActions referred to in [1] have many problems which need to be addressed before they enter general usage: - They are not well defined - They are not well defined enough to compute over - There is no well defined means of extension - There is no active community - There is no means to specify action parameters - The vocabulary of current actions is not sufficient to do anything now - ... They are not well defined - The main indie-action tag is used to wrap any third party/silo action buttons/links. What exactly is a third party action? Are schema.org actions supported? If so, how does the schema.org target attribute interact with the indie-action with attribute? If schema.org actions are not supported, what third party actions are? Explicitly, how do the URL templates, say, of such unspecified third party actions interact with the indie-action with attribute?Basically, this document[1] needs much work before it can be said to define an indie-action. They are not well defined enough to compute over - Assume a dailer web app presents a indie-action tag corresponding to a dial action. (This is a simple use case that we have to be able to handle. This is not an edge case.) Assume further that there was a well defined means of adding actions so such an action could even exist. Does the indie-action tag for the dial action contain a URL for every possible number it can dial? (The description of [1] never uses anything like URL templates. So, this seems to imply that only non-template URL's are allowed.) Assuming that this was a mistake in the description of [1] and URL templates are allowed, how does one specify the type of a URL template argument. In other words, could I pass fldska as a telephone number? This is never touched uponAgain, it's obvious here that much work is needed before the document[1] can be said to define an indie-action that is able to be computed over. There is no well defined means of extension - How do I add a new action? This is not mentioned. (There is mention made of one possible new verb tip[2], but no detail is given on its meaning. It's only stated tip - for Flattr, Gittip buttons and maybe other payment providers.) Mention is made that we can create a common verb registry like the rel registry, but no registry is ever presented nor is the means to register in such a registry if it even existed. Again, this needs lots of work which hasn't been done. There is no active community - The last entry in the History section of [1] is from 2012. In contrast, the last entry in the schema.org github repository[3] is from yesterday. There is no means to specify action parameters - There is no mention of how an action is parameterized. Again, a simple example. For a dailer web app that exposes the dialing web action to dial an arbitrary phone number. How is this dail action exposed with WebActions? There is no specification or discussion of how this would occur. We can't possibly have a fixed URL for all possible numbers; there has to be some type of URL template that one can specify. There is no mention made of this. Again, this needs work. The vocabulary of current actions is not sufficient to do anything now - The only actions that exist now are post, reply, repost, and like (and maybe tip), and there is no official means to add new actions. So, what if we wanted a dial action? Currently this is impossible. With the current limited vocabulary and no means to add new actions, WebActions is a non-starter for my use cases and those of Taipei. TL;DR: WebActions, as presented in [1], are not sufficiently well developed for us to base an implementation upon. With lots of additional work, they could one day form the basis of an implementation, but, as a target for FirefoxOS 2.5, they are simply not there yet. [1] http://indiewebcamp.com/webactions [2] http://indiewebcamp.com/webactions-verbs-brainstorming [3] https://github.com/schemaorg/schemaorg/commits/sdo-ganymede -- Kelly Davis Bringing a voice to Firefox OS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Linked Data must die. (was: Linked Data and a new Browser API event)
On 2 July 2015 at 03:37, Tantek Çelik tan...@cs.stanford.edu wrote: tl;dr: It's time. Let's land microformats parsing support in Gecko as a Q3 Platform deliverable that Gaia can use. Happy to hear this! I think there's rough consensus that a subset of OG, as described by Ted, satisfies this. Minimizing our exposure to OG (including Twitter Cards) is ideal for a number of reasons (backcompat/proprietary maintenance etc.). That's certainly a good start. It seems a shame to intentionally filter out all the extra meta tags used by other Open Graph types like: - music.song - music.album - music.playlist - music.radio_station - video.movie - video.episode - video.tv_show - article - book - profile - business - fitness.course - game.achievement - place - product - restaurant.menu I envisage allowing the community to contribute addons to add extra experimental card packs for types we don't support out of the box from day one. Filtering out this data would make it very difficult for them to do that, for no good reason. I absolutely understand the argument about having to maintain backwards compatibility with a format if we don't want to promote it going forward though, which is why I agree we should be conservative when adding built-in Open Graph types. There appear to be multiple options for this, with the best (most open, aligned with our mission, already open source interoperably implemented, etc.) being microformats. That is your opinion. There may be things you don't like about JSON-LD for example, but it is a W3C Recommendation created through a standards body and has open source implementations in just as many languages as Microformats. There may be other more subjective measures of open you're talking about, but I think it would be better for us all to stick to arguments about technical merit and adoption statistics when making comparisons in this case, at the risk of falling into the Not Invented Here trap. fulfils mostly in theory. Schema is 99% overdesigned and aspirational, most objects and properties not showing up anywhere even in search results (except generic testing tools perhaps). A small handful of Schema objects and subset of properties are actually implemented by anyone in anything user-facing. As I mentioned, level of current usage is not the most important criteria for Gaia's own requirements, but if we're talking about how proven these schemas are, according to schema.org these are the number of domains which use the schemas we're talking about: - Person - over 1,000,000 domains - Event - 100,000 - 250,000 domains - ImageObject - over 1,000,000 domains - AudioObject - 10,000 - 50,000 domains - VideoObject - 100,000 - 200,000 domains - RadioChannel - fewer than 10 domains - EmailMessage - 100 - 1000 domains - Comment - 10,000 - 50,000 domains The only equivalent data I have for Microformats is for hCard (equivalent to the Person schema) from a crawl at the end of last year [1], and it has about the same usage: - hCard - 1,095,517 domains The data also shows that Microdata and RDFa are used on more pages per domain than Microformats. I'd say that Microformats looks at best equally as unproven on that basis, though I'm open to new data. Everything else is untested, and claiming fulfils these use cases puts far too much faith in a company known for abandoning their overdesigned efforts (APIs, vocabularies, syntaxes!) every few years. Google Base / gData / etc. likely fulfilled these use cases too. Our Gecko and Gaia code is not going to stop working if Google decides to use something else. Content authors on the wider web might migrate to newer vocabularies (or even syntaxes) over time, but that's something we're going to have to monitor on an ongoing basis anyway. Existing interoperably implemented microformats support most of these: - Contact - http://microformats.org/wiki/h-card - Event - http://microformats.org/wiki/h-event - Photo - http://microformats.org/wiki/h-entry with u-photo property - Song - no current vocabulary - classic hAudio vocabulary could be simplified for this - Video - http://microformats.org/wiki/h-entry with u-video property - Radio station - no current vocabulary - worth researching with schema RadioChannel as input - Email - http://microformats.org/wiki/h-entry with u-in-reply-to property - Message - http://microformats.org/wiki/h-entry OK, so there are actually three Microformats that are useful to us here. For photos, videos, emails and messages we have to re-use the same hEntry Microformat and try to figure out from its properties which type of thing it is. For song and radio station we'd need to invent something new. This is not very attractive for Firefox OS where we'd like to have cleary defined types of cards with different card templates. It also makes it harder for the community to create new types of cards (e.g. via addons)
Re: Linked Data must die. (was: Linked Data and a new Browser API event)
This thread has been fun to follow. There are only 2 hard problems in Comp Sci and naming things is one of them ;). Just wanted to quickly chip in: during our lively discussion about naming, let’s not forget Postel’s Law. It’s smart to debate which format we should encourage for _publishing_. It’s wise to be liberal in what formats we _accept_. So we can encourage developers to use the solution we think is best, while simultaneously falling back to anything reasonable that’s there. og:x, twitter:y, Microformats... if it’s being actively used on the web we would be silly to turn up our nose at good data! --- Gordon Brander Sr Design Strategist Mozilla On July 2, 2015 at 10:59:15 , Benjamin Francis (bfran...@mozilla.com) wrote: On 2 July 2015 at 03:37, Tantek Çelik wrote: tl;dr: It's time. Let's land microformats parsing support in Gecko as a Q3 Platform deliverable that Gaia can use. Happy to hear this! I think there's rough consensus that a subset of OG, as described by Ted, satisfies this. Minimizing our exposure to OG (including Twitter Cards) is ideal for a number of reasons (backcompat/proprietary maintenance etc.). That's certainly a good start. It seems a shame to intentionally filter out all the extra meta tags used by other Open Graph types like: - music.song - music.album - music.playlist - music.radio_station - video.movie - video.episode - video.tv_show - article - book - profile - business - fitness.course - game.achievement - place - product - restaurant.menu I envisage allowing the community to contribute addons to add extra experimental card packs for types we don't support out of the box from day one. Filtering out this data would make it very difficult for them to do that, for no good reason. I absolutely understand the argument about having to maintain backwards compatibility with a format if we don't want to promote it going forward though, which is why I agree we should be conservative when adding built-in Open Graph types. There appear to be multiple options for this, with the best (most open, aligned with our mission, already open source interoperably implemented, etc.) being microformats. That is your opinion. There may be things you don't like about JSON-LD for example, but it is a W3C Recommendation created through a standards body and has open source implementations in just as many languages as Microformats. There may be other more subjective measures of open you're talking about, but I think it would be better for us all to stick to arguments about technical merit and adoption statistics when making comparisons in this case, at the risk of falling into the Not Invented Here trap. fulfils mostly in theory. Schema is 99% overdesigned and aspirational, most objects and properties not showing up anywhere even in search results (except generic testing tools perhaps). A small handful of Schema objects and subset of properties are actually implemented by anyone in anything user-facing. As I mentioned, level of current usage is not the most important criteria for Gaia's own requirements, but if we're talking about how proven these schemas are, according to schema.org these are the number of domains which use the schemas we're talking about: - Person - over 1,000,000 domains - Event - 100,000 - 250,000 domains - ImageObject - over 1,000,000 domains - AudioObject - 10,000 - 50,000 domains - VideoObject - 100,000 - 200,000 domains - RadioChannel - fewer than 10 domains - EmailMessage - 100 - 1000 domains - Comment - 10,000 - 50,000 domains The only equivalent data I have for Microformats is for hCard (equivalent to the Person schema) from a crawl at the end of last year [1], and it has about the same usage: - hCard - 1,095,517 domains The data also shows that Microdata and RDFa are used on more pages per domain than Microformats. I'd say that Microformats looks at best equally as unproven on that basis, though I'm open to new data. Everything else is untested, and claiming fulfils these use cases puts far too much faith in a company known for abandoning their overdesigned efforts (APIs, vocabularies, syntaxes!) every few years. Google Base / gData / etc. likely fulfilled these use cases too. Our Gecko and Gaia code is not going to stop working if Google decides to use something else. Content authors on the wider web might migrate to newer vocabularies (or even syntaxes) over time, but that's something we're going to have to monitor on an ongoing basis anyway. Existing interoperably implemented microformats support most of these: - Contact - http://microformats.org/wiki/h-card - Event - http://microformats.org/wiki/h-event - Photo - http://microformats.org/wiki/h-entry with u-photo property - Song - no current vocabulary - classic hAudio vocabulary could be simplified for this - Video -
Re: Linked Data must die. (was: Linked Data and a new Browser API event)
On Thu, Jul 2, 2015 at 11:47 AM, Gordon Brander gbran...@mozilla.com wrote: This thread has been fun to follow. There are only 2 hard problems in Comp Sci and naming things is one of them ;). Just wanted to quickly chip in: during our lively discussion about naming, let’s not forget Postel’s Law. It’s smart to debate which format we should encourage for _publishing_. It’s wise to be liberal in what formats we _accept_ Hmm... I'm not sure Postel was really referring to this kind of case so much as about specification compliance. In any case, I think there's an argument to be made that supporting a lot of format is not a good thing. See also:: http://datatracker.ietf.org/doc/draft-thomson-postel-was-wrong/ -Ekr So we can encourage developers to use the solution we think is best, while simultaneously falling back to anything reasonable that’s there. og:x, twitter:y, Microformats... if it’s being actively used on the web we would be silly to turn up our nose at good data! --- Gordon Brander Sr Design Strategist Mozilla On July 2, 2015 at 10:59:15 , Benjamin Francis (bfran...@mozilla.com) wrote: On 2 July 2015 at 03:37, Tantek Çelik wrote: tl;dr: It's time. Let's land microformats parsing support in Gecko as a Q3 Platform deliverable that Gaia can use. Happy to hear this! I think there's rough consensus that a subset of OG, as described by Ted, satisfies this. Minimizing our exposure to OG (including Twitter Cards) is ideal for a number of reasons (backcompat/proprietary maintenance etc.). That's certainly a good start. It seems a shame to intentionally filter out all the extra meta tags used by other Open Graph types like: - music.song - music.album - music.playlist - music.radio_station - video.movie - video.episode - video.tv_show - article - book - profile - business - fitness.course - game.achievement - place - product - restaurant.menu I envisage allowing the community to contribute addons to add extra experimental card packs for types we don't support out of the box from day one. Filtering out this data would make it very difficult for them to do that, for no good reason. I absolutely understand the argument about having to maintain backwards compatibility with a format if we don't want to promote it going forward though, which is why I agree we should be conservative when adding built-in Open Graph types. There appear to be multiple options for this, with the best (most open, aligned with our mission, already open source interoperably implemented, etc.) being microformats. That is your opinion. There may be things you don't like about JSON-LD for example, but it is a W3C Recommendation created through a standards body and has open source implementations in just as many languages as Microformats. There may be other more subjective measures of open you're talking about, but I think it would be better for us all to stick to arguments about technical merit and adoption statistics when making comparisons in this case, at the risk of falling into the Not Invented Here trap. fulfils mostly in theory. Schema is 99% overdesigned and aspirational, most objects and properties not showing up anywhere even in search results (except generic testing tools perhaps). A small handful of Schema objects and subset of properties are actually implemented by anyone in anything user-facing. As I mentioned, level of current usage is not the most important criteria for Gaia's own requirements, but if we're talking about how proven these schemas are, according to schema.org these are the number of domains which use the schemas we're talking about: - Person - over 1,000,000 domains - Event - 100,000 - 250,000 domains - ImageObject - over 1,000,000 domains - AudioObject - 10,000 - 50,000 domains - VideoObject - 100,000 - 200,000 domains - RadioChannel - fewer than 10 domains - EmailMessage - 100 - 1000 domains - Comment - 10,000 - 50,000 domains The only equivalent data I have for Microformats is for hCard (equivalent to the Person schema) from a crawl at the end of last year [1], and it has about the same usage: - hCard - 1,095,517 domains The data also shows that Microdata and RDFa are used on more pages per domain than Microformats. I'd say that Microformats looks at best equally as unproven on that basis, though I'm open to new data. Everything else is untested, and claiming fulfils these use cases puts far too much faith in a company known for abandoning their overdesigned efforts (APIs, vocabularies, syntaxes!) every few years. Google Base / gData / etc. likely fulfilled these use cases too. Our Gecko and Gaia code is not going to stop working if Google decides to use something else. Content authors on the wider web might migrate to newer vocabularies (or even
Re: Linked Data must die. (was: Linked Data and a new Browser API event)
This. I don't want to lose Jonas' point in this long thread, but I also haven't read anything here that warrants new native parser(s) yet. Let's iterate in Gaia for now. I don't see how a C++ metadata parser is advantageous at this point, and the RDF history lessons certainly don't encourage that path. --Jet On Wed, Jul 1, 2015 at 11:11 PM, Jonas Sicking jo...@sicking.cc wrote: I'd definitely like to keep the implementation of whatever formats we use in Gaia given that this is still an experimental feature and the use cases are likely to evolve as we get user feedback.reiterate the ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
