Re: To what extent is sccache's distributed compilation usable?

[Marcos Caceres]

On Wednesday, October 30, 2019 at 11:59:45 PM UTC+11, Jeff Muizelaar wrote:
> On Tue, Oct 29, 2019 at 9:45 PM Marcos Caceres  wrote: 
> sccache supports doing cross compilation so you don't actually need to
> buy a fast Mac to get fast Mac builds. A fast cheap Linux desktop will
> get you much better bang for your buck.

Now that we are all be stuck at home for 1-2 months, might be fun to revisit 
this :) 

If anyone manages to get sccache working across multiple Macs/Linux boxes at 
home, could you post some instructions on how to get it going? 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: You can use UTF8String from WebIDL

[Marcos Caceres]

On Monday, January 6, 2020 at 12:51:56 PM UTC+11, Emilio Cobos Álvarez wrote:
> If you need UTF-8 inputs from WebIDL (for example if you are passing the 
> input to Rust), chances are you're doing an extra copy from JS.
> 
> In bug 1449861 I've added an UTF8String so that you can convert a 
> JSString to UTF-8 in a single operation, instead of going through UTF-16.

this seems great. Is there a proposal to add this to the WebIDL spec or are we 
just planning to use it as an optimization internally just for us? My worry is 
having to keep IDL from specs and internal in sync (not a big deal, but always 
nice to have a single source of truth). 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Web Payments Working Group

[Marcos Caceres]

On Wednesday, December 4, 2019 at 1:58:54 AM UTC+11, L. David Baron wrote:
> 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.

Feedback I send a little while back:
https://lists.w3.org/Archives/Public/public-payments-wg/2019Nov/.html

My proposed changes were accepted in the charter. FWIW, I'm personally happy 
with the charter and the scope. I'd like for Mozilla to continue to support 
this WG. 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: To what extent is sccache's distributed compilation usable?

[Marcos Caceres]

On Wednesday, October 30, 2019 at 4:53:55 AM UTC+11, Steve Fink wrote: 
> I really ought to put my decade-old desktop into action again. My last 
> attempt was with icecc, and though it worked pretty well when it worked, 
> the pain in keeping it alive wasn't worth the benefit.

Thanks Steve... so it does really sound like perhaps just investing in more 
individual computing power might be the way to go. I think that's ok... even if 
it means, in my own case, personally paying the extra "Apple Tax" for a Mac Pro 
once they are released (I guess I'd be looking at ~US$10,000). The increased 
productivity might make it worth it tho.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: To what extent is sccache's distributed compilation usable?

[Marcos Caceres]

On Tuesday, October 29, 2019 at 3:27:52 AM UTC+11, smaug wrote:
> Quite often one has just a laptop. Not compiling tons of Rust stuff all the 
> time would be really nice.
> (I haven't figured out when stylo decides to recompile itself - it seems to 
> be somewhat random.)

Probably a gross misunderstanding on my part, but the sccache project page 
states [1]: "It is used as a compiler wrapper and avoids compilation when 
possible, storing a cache in a remote storage using the Amazon Simple Cloud 
Storage Service (S3) API, the Google Cloud Storage (GCS) API, or Redis."

I'm still (possibly naively) imagining that we will leverage the "the cloud"™️ 
to speed up compiles? Or am I totally misreading what the above is saying? 

[1] https://github.com/mozilla/sccache#sccache---shared-compilation-cache
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: To what extent is sccache's distributed compilation usable?

[Marcos Caceres]

On Saturday, October 26, 2019 at 11:47:51 PM UTC+11, Emilio Cobos Álvarez 
wrote: 
> So you have two options, I think:
> 
>   * Setup a Linux box as an sccache-dist scheduler and builder. This 
> should require no SDKs or what not, but requires some setup in your mac 
> as described here[1]. Then you'd just do regular sccache-enabled ./mach 
> build from your Mac, which would then distribute work to your Linux box.

I think I'll try option 1... I have an old Surface Pro running Ubuntu which I 
can use as the scheduler. It's probably too underpowered to be helpful in 
compiling... but you never know - every CPU helps, I guess... even at 1GHz. 
Then I've got a couple of old (2014) MacBook Pros to throw into the mix, which, 
together with my 2018 MacBook Pro should get me to around 20+ CPUs. I guess if 
that works, I can look at buying some cheap Linux setup with Ryzen in it to 
feed it more CPUs. 

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: To what extent is sccache's distributed compilation usable?

[Marcos Caceres]

On Friday, October 25, 2019 at 4:14:05 AM UTC+11, Jeff Gilbert wrote:
> My home Ryzen 3900x builds windows debug clobbers in under 10 minutes.

Whoa, that's awesome! 

> Beefy desktops are relatively cheap, and I believe we continue to encourage
> firefox-builders to request desktop workstations for builds.

Do you know if it's possible to cross compile on one of those for to target 
MacOS? I'd like to build on, and for, MacOS. 

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: To what extent is sccache's distributed compilation usable?

[Marcos Caceres]

On Thursday, October 24, 2019 at 6:46:08 AM UTC+11, Christopher Manchester 
wrote:
> As announced in this week's project call, sccache-dist schedulers have been
> deployed to mozilla offices, and those with hardware available can enroll
> servers based on the documentation here
> .

Just a reminder to not forget about us remotees! We are dying out here with 1+ 
hour compile times so anything would really help (even 20-20% improvement would 
go a long way). A lot of us have spare old macs, and if we can put them to good 
use with this, that would be amazing.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Web Speech API

[Marcos Caceres]

On Monday, October 7, 2019 at 12:55:23 PM UTC+11, Marcos Caceres wrote:
> As of October 11th, the Emerging Technologies Team intend to turn "Web Speech 
> API" on by default in *Nightly only* on Mac, Windows, and Linux. It has been 
> developed behind the "media.webspeech.recognition.*" and 
> "media.webspeech.synth" preference. 
> 

Note that because this is only being pref'ed on in Nightly, it should be 
considered a kind of "intent to experiment". This is to allow the ET team to 
get a better understanding of what need to be fixed to get better interop and 
what needs to be fixed in the spec. Concerns with the current spec around 
outlined in:

https://github.com/mozilla/standards-positions/issues/170

Collaboration with Google folks is ongoing to address some of those at the spec 
level. 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Web Speech API

[Marcos Caceres]

(Apologies for top-posting. I've asked the folks from ET to reply to the 
questions - Andre said he will respond soon! I was just helping them post the 
Intent, but I'm personally not involved with the implementation so I can't 
answer these really good questions... I'm just helping with our process stuff 
:)).

On Monday, October 7, 2019 at 8:32:18 PM UTC+11, Jonathan Kew wrote:
> On 07/10/2019 09:53, Henri Sivonen wrote:
> > On Mon, Oct 7, 2019 at 5:00 AM Marcos Caceres  wrote:
> 
> >>   - speech is processed in our cloud servers, not on device.
> > 
> > What should one read to understand the issues that lead to this change?
> 
> +1. This seems like a change of direction which has *huge* implications 
> for issues like availability (the feature doesn't work if my device is 
> offline?), privacy (my device is sending microphone input to the 
> cloud?), and cost (how much of my expensive metered data does this 
> gobble up?) that need to be openly considered and discussed.
> 
> The original "Intent to prototype" seemed to be about an entirely 
> device-local feature, which means it had fundamentally different 
> characteristics.
> 
> Thanks,
> 
> JK

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to prototype: Web Share Target

[Marcos Caceres]

On Saturday, October 5, 2019 at 12:28:24 AM UTC+10, David Burns wrote:
> Is this something that we could be tested with testdriver.js inside wpt?

It's complicated because every handles installation differently in their 
respective UIs (and it can chance from one browser version to another). 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: Web Speech API

[Marcos Caceres]

As of October 11th, the Emerging Technologies Team intend to turn "Web Speech 
API" on by default in *Nightly only* on Mac, Windows, and Linux. It has been 
developed behind the "media.webspeech.recognition.*" and 
"media.webspeech.synth" preference. 

Other UAs shipping this or intending to ship it are Chrome, and Safari (speech 
synth only, not recognition).

Bug to turn on by default: https://bugzilla.mozilla.org/show_bug.cgi?id=1244237

This feature was previously discussed in this "Intent to prototype" thread: 
https://groups.google.com/d/msg/mozilla.dev.platform/uM3NzS3hKkk/KsWBbf0BRIEJ

What's new since 2014?:

 - The updated implementation more closely aligns with Chrome's implementation 
- meaning we get better interop across significant sites.  
 - adds the ability to do speech recognition on a media stream.
 - speech is processed in our cloud servers, not on device. 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Web Commerce Interest Group

[Marcos Caceres]

Hi Tantek,

bcc: Ian Jacobs, who is the W3C Team contact and activity lead.

On July 18, 2017 at 9:58:40 AM, Tantek Çelik (tan...@cs.stanford.edu) wrote:
> I'd like to hear feedback from Marcos (cc'd) on how/why this group
> will complement or help our work in the Web Payments WG (does not seem
> to be addressed by the proposed Commerce IG charter).

I think it's great if that group goes off to collect use cases and
requirements - we have a good 2-5 year gap between seeing adoption of
just "basic-card" and possibly some custom payment solutions (via the
Payment Handler API). So, the IG can collect requirements and
eventually bring them back to the WG.

It seems like an oversight that the charter doesn't say they would
collaborate with the Web Payment WG - as eventually, whatever they do
find, the WG will potentially standardize. We could simply point that
out (hi Ian!), but I honestly just think it was an oversight because
there is so much overlap with the folks from both groups.

HTH!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: W3C Charter Advance Notice: Web Platform (recharter) & Service Workers WGs

[Marcos Caceres]

On July 6, 2017 at 1:40:13 PM, L. David Baron (dba...@dbaron.org) wrote:
> I've taken what you (Tantek) wrote and made minor changes to yield
> the following Formal Objection to the Web Platform WG charter.

I support the updated formal objection. Thanks Tantek for drafting it.

I've raised these issues also here:
https://github.com/w3c/charter-html/issues/145

Where Domenic also pointed out that the following are being copy/pasted:

* Web Sockets API
* Web Workers
* HTML Canvas 2D Context

And the WG should cease to publish any errata for "specs under
maintenance" (as those are all WHATWG, I think), except for
"view-mode", which we should maybe consider asking them to obsolete.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to put Permission API's .revoke() method behind a pref

[Marcos Caceres]

On August 17, 2016 at 5:02:07 PM, Anne van Kesteren (ann...@annevk.nl) wrote:
> On Wed, Aug 17, 2016 at 6:48 AM, wrote:
> > There is consensus that .query() is beneficial, so that one can remain.
>
> Is there really?

Well, the use case at least: that a developer should not need to
actually invoke the API to check if permission has been granted.

> The main problem with query as I see it is that since we haven't
> agreed on what permissions are keyed on, an application cannot really
> do anything with the answer it gets from query. E.g., communicating
> the answer with other open tabs and then attempting to use the
> permission there is futile for certain permissions. That kind of thing
> would only work if they are all origin-keyed, but some are per
> session, some are scoped to the top-level browsing context, etc.

Well, it covers the 80% case (specially on mobile, where tabs are not
at useful). But yeah...  the model is not there :(

We should maybe also pref .query() too... wdyt?

> (I support not exposing revoke() though. Was there even an intent to
> ship for that?)

I think it slipped through with:
https://groups.google.com/d/msg/mozilla.dev.platform/7RnCrXoXdG4/Oy84atEoKgAJ

We might need to be more careful in the future about granularity of
intent to ship to particular methods.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to put Permission API's .revoke() method behind a pref

[marcos]

Summary: It seems we prematurely shipped the .revoke() method on the 
Permissions API before it was stable or deciding if we even wanted it in the 
platform. 

For those that don't know it: navigator.permission.revoke() allows a site to 
self-revoke a permission after a user has granted that permission. For example, 
a user may grant foo.com access to geolocation, but upon signing out of a site, 
a site might call .revoke({name:"geolocation"}) so that the next user to log 
into the site doesn't automatically get access to geolocation (as permissions 
are bound to origin).

A few folks (who can chime in) working on the standard have raised concerns 
about the API, so we would like to suggest we put it behind a pref for now. 
Particularly, using in-browser user profiles can handle the above use case 
without a site taking away a user's decision. 

There is consensus that .query() is beneficial, so that one can remain. 

Bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1295877

Link to standard:
https://w3c.github.io/permissions/#dom-permissions-revoke

Platform coverage: All.

Estimated or target release: Firefox 51

Preference behind which this will be implemented:
dom.permissions.revoke.enable

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Non-standard stuff in the /dom/ directory

[marcos]

I'm wondering, would it be worth while cleaning up the dom/ directory to move 
non-standard stuff out of there? 

There is a bunch of legacy stuff from B2G that could be moved out to, say, 
b2g/apis or some such for historical reasons.

It would make searching/working-with for standardized DOM related stuff much 
easier. 

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Web of Things Interest Group

[marcos]

On Tuesday, June 14, 2016 at 7:06:39 PM UTC+10, David Baron wrote:

> 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.

It seems to go off into the RDF/XML weeds and tries to mask itself as something 
different to IoT (whatever that is). I think we should oppose it as it seems 
that whatever the result is, will not be Web friendly (in the sense that it 
won't work with web browsers, JS APIs, etc.).
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement W3C Manifest for web application

[marcos]

On Wednesday, July 15, 2015 at 3:34:42 PM UTC+10, Anne van Kesteren wrote:
> On Wed, Jul 15, 2015 at 12:00 AM,   wrote:
> >  * It's not clear what problems manifest solves
> 
> This is by far the biggest problem. I think we ended up with manifests
> because packages have manifests and iOS/Android use packages for
> applications, but none of that translates well to the web.

Forgot to address this one - why we ended up with manifests is not important if 
we are starting from scratch.

Before we get to "what problems manifest solves", let's go back to vision and 
where some people, but maybe not all people here, want to take the Web: some 
people believe that web applications should be "installable"; That it should be 
possible to install them to the homescreen of a device; that they should 
integrate with OS permissions and services; that they should be managed in an 
indistinguishable manner to native applications. And there is a belief that 
users want this too, presumably because of the popularity of apps stores and 
apps downloaded from them. This doesn't necessarily mean installing a web 
application from an applications store - but rather from the URL from where the 
application is accessed.

Do we even agree on the above? Be good to know 'cause I honestly don't know 
what people want or what vision they have for the Web anymore here. Maybe we 
should go to just focusing on browser tabs - or building a better webview 
component? I dunno. Lack of shared vision and agreement makes this and 
extremely difficult problem to solve in any collaborative manner.

Now, Web manifest doesn't solve all "installability" aspects [1]. Its role is 
in providing the metadata needed to do the following (i.e., "what problems 
manifest solves" are these):
 
 * to help put an icon on the homescreen, and provide a bit more power than 
.  
 * start up parameters: it tells the runtime what orientation to launch in and 
lock to before anything is displayed (to avoid a crap experience of changing 
orientation after the application starts).
 * display mode: start the app in fullscreen, or with some chrome.
 * app scope: the URL space to which the manifest applies.
 * Splash screens: self explanatory.

[1] 
https://infrequently.org/2015/06/progressive-apps-escaping-tabs-without-losing-our-soul/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement W3C Manifest for web application

[marcos]

On Wednesday, July 15, 2015 at 3:34:42 PM UTC+10, Anne van Kesteren wrote:
> On Wed, Jul 15, 2015 at 12:00 AM,   wrote:
> >  * It's not clear what problems manifest solves
> 
> This is by far the biggest problem. I think we ended up with manifests
> because packages have manifests and iOS/Android use packages for
> applications, but none of that translates well to the web.
> 
> >  * Extra HTTP request could yield a performance penalty (even if 
> > deprioritized)... though probably not a concern in a HTTP2 world.
> 
> It's still a concern. You'll still need to duplicate all the metadata
> that the client needs immediately in the HTML.

We were careful to not have any immediately required metadata in the manifest. 
The stuff in the manifest is only applied after the web application is 
installed to a user's device and the application is run from the home screen 
(see Chrome's implementation). 
  
> One reason that was mentioned in favor of manifests was "don't repeat
> yourself". The way the web has dealt with that for two decades is
> server-side templating.

You might be forgetting, you know,  and 

Re: Intent to implement W3C Manifest for web application

[marcos]

(Please kindly cc me if you want my attention in this thread. I don't subscribe 
to mailing lists.) 

On Friday, April 18, 2014 at 7:22:56 AM UTC+10, Marcos Caceres wrote:
> Summary:  
> JSON-based manifest, which provides developers with a centralized place to 
> put metadata associated with a web application. This includes, but is not 
> limited to, the web application's name, links to icons, as well as the 
> preferred URL to open when the user launches the web application. The 
> manifest also allows developers to declare a default orientation for their 
> web application, as well as how the application is to be displayed by the 
> user agent (e.g., in fullscreen).  
> 
> Bug:  
> https://bugzilla.mozilla.org/show_bug.cgi?id=997779 
> 
> Link:  
> http://w3c.github.io/manifest/ 
> 
> Platform coverage: 
> All.  
> 
> Estimated or target release:  
> Q3 or Q4, 2014 

A few people have reached out to me with concerns about implementing web 
manifest in Gecko and have asked me to restart this thread (given that no one 
objected the first time around). There are concerns about the utility of Web 
manifests, the overall vision of "appifying" the Web, and their purpose given 
that the essentially replicate functionality in well-established and widely 
used  elements. 

Some of the things raised: 

 * It's not clear what problems manifest solves: do we really want to replicate 
"native app" installation behavior on the Web? We don't have a good history of 
making this work in various products. 
 * Extra HTTP request could yield a performance penalty (even if 
deprioritized)... though probably not a concern in a HTTP2 world. 
 * Can't we just use meta tags (application-name, etc.)? 
 * App-scope is as bad, or worst, than scope in service workers (i.e., you only 
get one directory in a domain, or the whole domain). 
 * How would Desktop firefox make use of display modes? (i.e., how would they 
work with tab browsing) 

Discuss! But please cc me, or else I might not read it :) 
___
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)

[Marcos Caceres]

On June 29, 2015 at 7:07:33 AM, Michael Henretty (mhenre...@mozilla.com) wrote:
> We will definitely start with the simple open graph stuff that Ted
> mentioned ("og:title", "og:type", "og:url", "og:image", "og:description")
> since they are so widely used. And yes, even these simple ones are
> problematic. For instance, when navigating between dailymotion videos they
> keep the current meta tags, and just updates the html body content. In
> fact, single-page-apps in general are hard here. Also, on the mobile
> version of youtube they leave out og tags entirely, probably as a
> performance optimization. Turns out, many sites do this. So in 2.5 we will
> have to account for all of this and the solution might not be pretty.

ok, it's good to see you've already started to encounter the issues. 

> I think Microformats addresses the aforementioned problems.

They might, though they can also change from under you in fun ways, or be 
invalid/incorrect. 

> But if youtube,
> wikipedia, pinterest, twitter, facebook, tumblr, etc don't use them widely
> what is the point of supporting them in a moz-internal API? Let's be
> pragmatic and start with og. What's the next biggest win for us? Is the
> data clear? Ben seems to think JSON-LD [1], does anyone have data to the
> contrary?

I don't have data, just some graying hair and warnings from the distant past 
[1]. You've all seen already how controversial these formats are, and hopefully 
you understand why now (expecting validity/sanity from the web is a non-starter 
- it's the fallacy of the semantic web, and why we mockingly call it the 
"pedantic web" and recoil in horror and lash out with rage at the mere mention 
of it). 

So flip the problem a bit: what you actually want is just simple data that can 
be transformed into a card, right? basically, we scrape some text values from a 
HTML page and you just put it into a different HTML document: the card. 

As long as you don't expect validity of that data (i.e., you don't expect a 
standards conforming JSON-LD, RDFa, microdata, microformat, whatever parser*) 
then that frees us to build some kind of HTML Scraper that is actually built 
for purpose (one that is fault tolerant, and basically doesn't give a crap what 
the RDFa or JSON-LD spec says, but is designed to aggressively find the data 
you need to build nice cards). This is also why I suggest you start with og: 
data, because it basically takes the same approach: it doesn't give a crap what 
the RDFa spec says (and neither do developers that add it to their pages, as 
I'm sure you've already seen), it just defines some things by using some HTML 
elements that kinda-sorta looks like RDFa. However, it comes with a ton of 
problems which you will have a great time trying to deal with as you build the 
pinned-sites feature. The same with Twitter's card format. 

At the end of the day, what Gecko should be passing back is a simple JS object 
that contains:

{
og: {... name/value pairs...}
twitter: {... name/value pairs...}
other_because_we_can_add_new_things_as_needed_yay: {... name/value pairs...}
}

If we are not going to be doing any semantic inferencing on that data or 
actually doing the "linked data" part, then we don't need a JSON-LD 
representation of it. We just need a fairly simple structure from which FxOS 
can build different cards. That avoids talk of supporting controversial formats 
like JSON-LD and RDFa, while actually supporting web content: in the sense 
that, "we are just pulling this 'og' meta stuff from the page, we don't care 
what it is".  

My 2c,

[1] Warning from 2003, that the same things happened with RSS. They had to 
abandon XML:
http://www.xml.com/pub/a/2003/01/22/dive-into-xml.html   

"I know, I know, this is how HTML got to be "tag soup": browsers that never 
complained. Now the same thing is happening in the RSS world because the same 
social dynamics apply. End users who can't even spell "XML" certainly don't 
care about silly little formatting rules; they just want to follow their 
favorite sites in their news aggregator. When 10% of the world's RSS feeds are 
not well-formed -- including some high-profile feeds that thousands of people 
want to read -- the ability to parse ill-formed feeds becomes a competitive 
advantage. (And if you think the same thing won't happen when RDF and the 
Semantic Web go mainstream, you're deluding yourself. The same social dynamics 
apply. Boy, is that going to be messy.)"



___
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)

[Marcos Caceres]

On Saturday, June 27, 2015, Benjamin Francis  wrote:

> On 26 June 2015 at 19:25, Marcos Caceres  > wrote:
>
>> Could we see some examples of the cards you are generating already with
>> existing data from the Web (from your prototype)? The value is really in
>> seeing that users will get some real benefit, without expecting developers
>> to add additional metadata to their sites.
>>
>
> The prototype only supports Open Graph, you can see some example cards in
> this video Pinning the Web - Prototoype
> <https://www.youtube.com/watch?v=FiLnRoRjD5k>
>

These look fantastic! so why not start with just those? Or are all those
card types done and thoroughly tested on a good chunk of Web content? As I
mentioned before, I'd be worried about the amount of error recovery
code that will be needed just for those types of cards. (Sorry, I don't
know any of the background and if you've already dealt with this).
___
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)

[Marcos Caceres]

On June 27, 2015 at 10:02:47 AM, Anne van Kesteren (ann...@annevk.nl) wrote:
> >
> The data I have does not back this up, Microdata is shown to be growing 
> fast whereas Microformats usage has remained relatively stable. 
> Also, we didn't find Microformats usage on any of the example 
> high profile sites we used during prototyping, it seems to be 
> more commonly used on Wordpress blogs and Indie Web style web 
> sites.

Could we see some examples of the cards you are generating already with 
existing data from the Web (from your prototype)? The value is really in seeing 
that users will get some real benefit, without expecting developers to add 
additional metadata to their sites.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement W3C Manifest for web application

[Marcos Caceres]

Summary:  
JSON-based manifest, which provides developers with a centralized place to put 
metadata associated with a web application. This includes, but is not limited 
to, the web application's name, links to icons, as well as the preferred URL to 
open when the user launches the web application. The manifest also allows 
developers to declare a default orientation for their web application, as well 
as how the application is to be displayed by the user agent (e.g., in 
fullscreen).  

Bug:  
https://bugzilla.mozilla.org/show_bug.cgi?id=997779 

Link:  
http://w3c.github.io/manifest/ 

Platform coverage: 
All.  

Estimated or target release:  
Q3 or Q4, 2014 


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement: HTML `picture` element

[Marcos Caceres]

Sending this on behalf of John Schoenick, who is doing the actual 
implementation.

#Summary 
The picture element finally brings responsive images to the Web! It allows 
developers to list multiple  and have the browser intelligently select 
one that is best suited for users (based on device capabilities, supported 
image formats, dpr, or possibly even a user preference). 

#Bug
https://bugzilla.mozilla.org/show_bug.cgi?id=870022

#Link to standard 
http://picture.responsiveimages.org/

# Platform coverage
All. 

# Estimated or target release: 
31/32 for landing, but parts may be pref'd off initially. 

# Other goodness
Parallel implementation happening on the Blink side! And positive signals from 
the WebKit community \0/.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: W3C Proposed Recommendations: XQuery, XPath, XSLT, EXI, API for Media Resources

[Marcos Caceres]

On October 29, 2013 at 10:02:14 AM, Henri Sivonen (hsivo...@hsivonen.fi) wrote:
>
>On Tue, Oct 29, 2013 at 1:39 AM, Ralph Giles wrote:
>> On 2013-10-28 2:11 PM, L. David Baron wrote:
>>> API for Media Resources 1.0
>>> http://www.w3.org/TR/mediaont-api-1.0/
>...
>> Thus I think we can be positive about this recommendation
>
>I would prefer to abstain or otherwise not endorse this specification
>for the following reasons:
>* It doesn't appear to integrate with HTML element interfaces and
>media fetching algorithms.
>* It seems unnecessary to standardize an API of this level of
>abstraction for Web apps that access server-side metadata repositories
>that are affiliated with the entity that serves the JavaScript
>program. The JavaScript program might as well have
>application-specific code.
>* This API appears to have Java-oriented bits and doesn't embrace the
>latest JS WebIDL API design thinking.
>* The API has a synchronous version.
>* There are RDF-style URI type identifiers.
>* It's not clear that this API would suit our use cases e.g. in
>Firefox OS gallery or music player.
>
>I would reply "abstain" and "don't plan to implement" for this API and
>on the XML related specs in this batch.

FWIW, Mike Smith of the W3C told them pretty much the above on the AC list - 
and made them add the following to the status section: 

“Nethertheless this API is not expected to be implemented natively in the 
browser code.” 

Doesn’t help much - but the authors and the W3C are well aware that this spec 
has little or no implementer interest. 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Studying Lossy Image Compression Efficiency

[Marcos Caceres]

On Tuesday, October 22, 2013 at 10:15 AM, pornel...@gmail.com wrote:

> On Tuesday, 22 October 2013 08:12:08 UTC+1, Yoav Weiss wrote:
> 
> > This is a part of Web traffic that would make enormous gains from an 
> > alpha-channel capable format, such as WebP or JPEG-XR (Don't know if 
> > HEVC-MSP has an alpha channel ATM), yet this is completely left out of the 
> > research. I think this point should be addressed.

I strongly agree with this. This is the killer feature why people want these 
new formats (apart from the byte savings) and is kinda weird that it was not 
part of the study. 

> If this is researched I'd love to see how it compares to lossy PNG from 
> pngquant2 http://pngquant.org and "blurizer" tool 
> https://github.com/pornel/mediancut-posterizer/tree/blurizer
That would be great.  
-- 
Marcos Caceres



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Suggested API exposure guidelines redux

[Marcos Caceres]

On Tuesday, 17 September 2013 at 21:42, Andrew Overholt wrote:
> Hi,
> 
> When we expose new things to web developers, I'd like us to consider 
> some suggestions. Due to a number of factors, I've made them 
> suggestions and not a set of pan-module hard rules.
> 
> https://wiki.mozilla.org/User:Overholt/APIExposurePolicy
> 
> I've incorporated lots of feedback given on previous revisions (thanks!) 
> and feel like this is ready to go.
> 
> Let me know if you want me to hold off on presenting these at an 
> upcoming Tuesday engineering meeting and moving them out of User:Overholt.
> 


In the Special Cases section, it should be made clear that these exceptions 
only apply to packaged and hosted apps - and not the browser that ships with 
Firefox OS.
It would be bad if the regular browser in Firefox OS exposed proprietary stuff. 

-- 
Marcos Caceres


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: New Promise Constructor

[Marcos Caceres]

On 11/09/2013, at 8:18 PM, Boris Zbarsky  wrote:

> On 9/11/13 2:13 PM, Marcos Caceres wrote:
>>> callback PromiseInit = void (object resolve, object reject);
>>> [Constructor(PromiseInit init)]
>>> interface Promise {...}
>> 
>> What members does PromiseInit dictionary have? ^_^
> 
> It's not a dictionary.  It's a callback, like the IDL snippet above says.
> 
> So you'd do it like so in practice:
> 
>  var p = new Promise(function(resolve, reject) {
>// do stuff here.
>  });

Ah, right! got confused as almost everything else in the platform with *Init is 
a dictionary. Maybe that should be renamed PromiseCallback. 

> 
> -Boris
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: New Promise Constructor

[Marcos Caceres]

On 11/09/2013, at 6:11 PM, Andrea Marchesini  wrote:

> Hi all,
> 
> I just want to inform that I'm landing a patch that changes the DOM Promise 
> constructor.
> DOM Promise is disabled by pref but I know that there are a few existing 
> pieces of code that already use them.
> 
> The old constructor was based the PromiseResolver object.
> Now we get rid of this object and the new constructor works in this way:
> 
> callback PromiseInit = void (object resolve, object reject);
> [Constructor(PromiseInit init)]
> interface Promise {...}
> 

What members does PromiseInit dictionary have? ^_^




> Best Regards,
> Andrea
> 
> 
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Detection of unlabeled UTF-8

[Marcos Caceres]

On Friday, September 6, 2013 at 5:36 PM, Neil Harris wrote:

> On 06/09/13 16:34, Gervase Markham wrote:
> > 
> > Data! Sounds like a plan.
> > 
> > Or we could ask our friends at Google or some other search engine to run
> > a version of our detector over their index and see how often it says
> > "UTF-8" when our normal algorithm would say something else.
> > 
> > Gerv
> This website has an interesting, and apparently up-to-date set of 
> statistics:
> 


Wait a minute, they also claim that XHTML is used on  54.9% of sites? I'm 
skeptical of their methodology. See:  

http://w3techs.com/technologies/overview/markup_language/all
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Ship: Web Audio

[Marcos Caceres]

On Tuesday, July 30, 2013 at 6:54 PM, Ehsan Akhgari wrote:

> On 2013-07-30 1:44 PM, Marcos Caceres wrote:
> 
> I have previously indicated our intent to ship to the working group for 
> Firefox 24, but that slipped. I need to update the working group on the 
> new plans.
> 
> Shipping Web Audio doesn't mean that we're necessarily happy with all 
> parts of the spec, but we're making trade-offs between having a good API 
> that everybody agrees on, and shipping code which works with some of the 
> existing content. We have heavily discussed these issues in the working 
> group.

Thanks for the clarifications.  


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Ship: Web Audio

[Marcos Caceres]

On Tuesday, July 30, 2013 at 6:26 PM, Ehsan Akhgari wrote:

> We have been working on implementing the Web Audio API for quite a while
> now, and we've had an experimental implementation on Nightly and Aurora for
> several cycles now.
> 
> We're getting close to a stage where we feel that we're ready to ship this
> API by default. 

What led you to feel comfortable with shipping? Is it based on interoperability 
with some significant content and another UA? Is there a test suite? 
> There is still some implementation work to be finished,
> and there are a few spec issues to be resolved, but we're relatively
> confident that we can address all of these issues by the time we release
> Firefox 25, therefore I would like to announce the intent to ship this API.

Ship means no longer behind a flag, right?  
> There is some risk involved from the spec level discussions which we're
> currently having in that the discussions may not finish in a timely
> manner. In that case, we will delay shipping this API until we reach a
> resolution on the W3C Audio Working Group, and I will follow-up to the list.
> 
> Please let me know if you have any questions.
> 

I'm admittedly a little bit concerned - if we ship, it's a strong signals to 
the W3C Web Audio WG we are happy with the API that is spec'ed as is (that may 
be true - it might be the best that the group can do and it might very well be 
a spec from which interoperable implementations can be created). My personal 
opinion about the spec is that it could be improved (lots of stuff seemed 
underspecified, etc. when I tried to read it a few months ago - but maybe it's 
better now) - if it mostly works across at least 2 browsers, then I guess it's 
time to ship.  

-- 
Marcos Caceres



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: AppCache usage on Alexa top ~50,000 sites

[Marcos Caceres]

On Thursday, 11 July 2013 at 18:02, Ian Hickson wrote:

> On Thu, 11 Jul 2013, Marcos Caceres wrote:
> >  
> > As a result of a discussion a few of us had today at the Toronto work  
> > week about the use of appcache on the web (and if we should "fix it"), I  
> > did a quick scan of the sites using appcache in Alexa's top ~50,000  
> > websites (only includes the landing page at a given URL).
> >  
> > Of the search, 16 sites were returned - 2 of which have appcache  
> > commented out. 1 site only enabled it for Mobile IE.
>  
>  
> Note that the main use case for appcache is applications, which tend to be  
> behind authentication walls and robots.txt blocks. For example, I would  
> doubt that a grep is going to catch Google Docs' use of appcache. (Not  
> that they want appcache to remain as is, but that's a separate issue.)

Sure. We have quite a few "hosted apps" for FireFox OS using it. Obviously, 
most of those sites are not going to show up in the index.   
> appcache is, in this respect, similar to  (which is almost not  
> used at all on the public web, but is used on intranets and behind  
> paywalls and authentication walls).

Agree… we were kinda interested in seeing if people were using it in unexpected 
ways. As I said, the data is just indicative (of what? I don't know!:)), and no 
conclusion should be drawn from it.   

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

AppCache usage on Alexa top ~50,000 sites

[Marcos Caceres]

As a result of a discussion a few of us had today at the Toronto work week 
about the use of appcache on the web (and if we should "fix it"), I did a quick 
scan of the sites using appcache in Alexa's top ~50,000 websites (only includes 
the landing page at a given URL).  

Of the search, 16 sites were returned - 2 of which have appcache commented out. 
1 site only enabled it for Mobile IE.

Details…  

The data is from June, 2013 and includes around 53,000 HTML files. It was 
downloaded from webdevdata.org. No user agent string was provided when 
retrieving the data. Please see webdevdata.org if you have questions about how 
the data is gathered.  

From the data, the search I did was:

`
for b in */*.txt; do ( grep -lm 1 "\smanifest\s*=" $b ); done
`

The results are not representative, but nonetheless throw a little weight 
towards the hypothesis that usage is generally low. A more in-depth look at 
usage is obviously needed and not too much should be read into this data. It's 
just a small data point.   

The sites were:  

metalsucks.net
capitalone.com
guinnessworldrecords.com
forecast.io
uni-due.de
littlealchemy.com
butfootballclub.fr
leovegas.com
netzkino.de
shopfato.com.br
giorgiotave.it
jsonlint.com
dragonbound.net
nordea.se
ex.fm

amardeshonline.com

--  
Marcos Caceres


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Making proposal for API exposure official

[Marcos Caceres]

Hi Andrew,  
Below is a review of the document. I've included the text and responded inline… 
 

On Sunday, 7 July 2013 at 15:24, Marcos Caceres wrote:
> Guidelines
>  
> Mozilla aims to advance the state of the open web with new APIs. Toward this 
> end,
>  
> Mozilla will not hurt the web by exposing a new web API in such a way that a 
> web developer can detect it (1) before it's ready.
I think "hurt" in the above is a bit too, um, I don't know… emotional?  

Maybe:  

In the last few years, Mozilla shipped experimental APIs with a "moz" prefix to 
indicate their lack of standardization (e.g., mozRequestAnimationFrame()). 
Unfortunately, this approach turned out to be harmful to the Web as 
experimental APIs ended up being used in websites before the APIs were ready. 
In many cases, this meant that we were unable to innovate on certain APIs 
because to change them would break content on the Web.  

To allow us to continue innovating without affecting content on the Web, 
Mozilla will no longer directly expose experimental APIs to the Web Platform 
using a vendor prefix. Instead, developers who want to road test experimental 
APIs, will need to explicitly enable them by going through `about:config`. Once 
we have agreement in the Web community about the stability of an API, and we 
feel it is ready, then we will make it generally available to the platform 
(more details below on this policy). We feel this strikes the right balance 
between allowing developers to experiment with new APIs, while at the same time 
protecting the Web from being exposed to new functionality prematurely. For 
more details, see Henri Sivonen's proposal.  

>  
> In the past we have shipped APIs with "moz" prefixes to indicate their lack 
> of standardization but we no longer do this. See Henri Sivonen's proposal.
>  
> Mozilla will not ship moz-prefixed web APIs
>  
> Scope
>  
> At this time, we are specifically focusing on new web APIs and non-trivial 
> changes to existing APIs. We are explicitly not focusing on CSS, WebGL, 
> WebRTC, network protocols, or other existing features/properties. In the 
> future, pending module owner agreement, we may extend this policy beyond web 
> APIs to other web-exposed features.
I think the above is a bad idea. Specially with regards to CSS, WebGL, etc. All 
experimental things should be behind a flag.  
> When is an API ready to be shipped by Gecko?
>  
> APIs which Mozilla makes available by default to the web on the release 
> channel should be standardized. This can mean that they are de jure standards 
> (ex. W3C recommendations) or de facto standards. Indications that an API is 
> standardized enough for shipping to the open web include:
>  
> other browser engines ship compatible implementations, either in their 
> release or in other channels with clear signals it will graduate to a release
> other browser engines state their intention to ship a compatible 
> implementation
> there exists a specification that is no longer at risk of significant 
> changes, is on track to become a standard with a relevant standards body, and 
> is acceptable to a number of applicable parties and other browser engines

Agree… though they are all a bit abstract. How is compatibility assessed (test 
suite, obviously… but still… or is it content)?  
Apart from the Google Dashboard, I think there was a table at the WHATWG of who 
has given a signal to support a particular part of HTML (at least). We should 
probably gather the things that will inform the above in some open and 
transparent manner.  
>  
> Mozilla seeks feedback from other browser engines during development and 
> implementation of web APIs.
How do we do this?  
> Lack of feedback will not stop our efforts
"Our efforts" is ambiguous: do you mean efforts to continue innovating or 
efforts to seek feedback?  
> as it may simply indicate lack of interest at that time from another browser 
> engine. We will attempt to reciprocate this feedback to other browser engines 
> when they are developing a feature or API that we believe to/will be 
> relevant, even if we won't implement it ourselves in the short term.
  
We should mention that we will be coordinating with the Chrome team with 
regards to this? Be good if we could also get some other browser folks to 
commit.  

> Exceptions
Maybe "Proprietary Features"? It's not really about about making an exceptions 
- as we won't make any exceptions for things that are for "the platform".  
>  
> New user-facing products like Firefox OS may need
It's not "may need to". It's a matter of fact that we do this - and we should 
not be sheepish about it.  
> to ship APIs that have not yet been embraced by other browser engines or 
> thorough

Re: Web MIDI API, was Re: Making proposal for API exposure official

[Marcos Caceres]

On Wednesday, July 3, 2013 at 12:16 PM, Robert O'Callahan wrote:

> On Wed, Jul 3, 2013 at 11:06 PM, Marcos Caceres  (mailto:mcace...@mozilla.com)> wrote:
> > On Wednesday, June 26, 2013 at 11:33 PM, Robert O'Callahan wrote:
> 
> 
> I'd like someone with experience implementing and maintaining APIs in Gecko 
> to have a good look at it as well. 
Fair enough. I have zero experience there.
> I think Olli would be a good choice :-).

Any spec problems, let me know and I can try to fix them. Otherwise, please 
file bugs here:
https://github.com/WebAudio/web-midi-api/issues



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Web MIDI API, was Re: Making proposal for API exposure official

[Marcos Caceres]

On Wednesday, June 26, 2013 at 11:33 PM, Robert O'Callahan wrote:

> I think we should try. So, we should try to have someone carve out some
> time to review Web MIDI, at least to the point where we feel confident it
> would make sense to implement.

I've been heavily involved with Web MIDI for about 8 months (most of the 
changes to the API can be traced back to bugs I've filed on it); I even wrote a 
reference implementation (prollyfill) of it in JS [1]. 

Having said that, the spec still needs some clarifications in some of the 
algorithms - but it's in fairly good shape and fairly close to "LC" quality, 
IMHO. Really just needs some spit-n-polish here and there. 

I'll probably set a bit of time aside in August to help Chris Wilson and Jussi 
finish it, as I think it's a pretty neat spec that will enable an interesting 
range of applications (judging by the amazing range of MIDI applications on 
iOS).   

Is there anything in particular you would like to see from a review? What would 
you expect to see to feel confident that it would make sense to implement it?  

[1] https://github.com/marcoscaceres/adlib.js 
-- 
Marcos Caceres



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: SpiderMonkey Regrets

[Marcos Caceres]

On Saturday, 29 June 2013 at 09:08, teramako wrote:

> I would want Mozilla to fix those issues rather than implementing new
> methods of ES.next and keep the top engine which has the most
> compatibility for ECMAScript.

I didn't quite get the rationale for why we should fix stuff that's 
non-standard instead of putting energy into the ES.next? Won't fixing 
non-standards things just encourage people to use it more and lead to more 
confusion/content (thus making it harder to do away with the non-standard 
stuff)? 

-- 
Marcos Caceres



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform