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

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 bfran...@mozilla.com wrote:

 On 26 June 2015 at 19:25, Marcos Caceres mar...@marcosc.com
 javascript:_e(%7B%7D,'cvml','mar...@marcosc.com'); 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

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 sources 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 6:11 PM, Andrea Marchesini amarches...@mozilla.com 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: New Promise Constructor

[Marcos Caceres]

On 11/09/2013, at 8:18 PM, Boris Zbarsky bzbar...@mit.edu 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: 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: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

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 
 thoroughly discussed by standards bodies. Products such as Firefox OS would 
 ship these APIs as a part of their product but not to the broader web, thus 
 clearly indicating their lack of standardization and limiting the number of 
 web developers relying upon them. When rare situations such as this arise, 
 API standardization must

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