Re: WebUSB

2015-12-09 Thread Tim Guan-tin Chien 
On Fri, Dec 4, 2015 at 7:01 PM, Robert O'Callahan  wrote:
>
> On Fri, Dec 4, 2015 at 2:43 PM, Eric Rescorla  wrote:
>
> >
> > Sure. Conversely, I don't find myself convinced by your position.
> >
> > Would be happy to talk about this live if you think that's useful.
> >
>
> Probably not ... these are judgement calls that are difficult to resolve.
>
> Rob

Rob,

IMHO there will be some detail to settle for (1) since that implies
hardware vendor has to host a driver for the device to work,
_forever_.

We could get around it by amending (1) into having vendor shipping a
JS library as driver, which fold it into (4) (if I understand it
correctly). But then we would lost the benefit of getting vendors to
supply security update timely and block bad API calls from apps.

I am leaning toward Ekr's opinion in this case. The way hardware
vendors divide their works also prevent the actual chip vendor (OEM)
from providing end user support (by at least host a driver).

Thanks,


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

Re: Single- vs. double-precision FP in gfx types

2015-12-09 Thread Nicholas Nethercote 
On Tue, Dec 8, 2015 at 4:34 PM, Nicholas Nethercote
 wrote:
>
> One interesting thing I found is that a *lot* of the functions that
> take an nsRenderingContext or gfxContext do so because they end up
> passing it into text run code -- gfxTextRun uses a gfxContext, via
> gfxTextRunFactory::Parameters::mContext. However, only a few things
> from the gfxContext are used by the text run code:
>
> - gfxContext::GetCairo() is called in numerous places.

I was able to find a bunch of functions that only needed
gfxContext::mRefCairo and so I've changed them to take a |cairo_t*|
instead of a |gfxContext*|, which clears things up a bit:
https://bugzilla.mozilla.org/show_bug.cgi?id=1231550

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

Re: WebUSB

2015-12-09 Thread Robert O'Callahan 
On Fri, Dec 4, 2015 at 4:56 PM, Eric Rescorla  wrote:

> (4) Have the APIs hidden behind access controls that need to be enabled by
> an extension
> (but a trivial one). Perhaps you think this is #2.
>

I realized I don't understand exactly what this means.

I assume "extension" means a privileged browser extension whose install is
gated on user opt-in. Who creates and maintains this extension? How is it
distributed and updated? Does it work cross-browser? Once it's installed,
what is its effect?

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Single- vs. double-precision FP in gfx types

2015-12-09 Thread Nicholas Nethercote 
On Wed, Dec 9, 2015 at 3:49 PM, Nicholas Nethercote
 wrote:
>>
>> One interesting thing I found is that a *lot* of the functions that
>> take an nsRenderingContext or gfxContext do so because they end up
>> passing it into text run code -- gfxTextRun uses a gfxContext, via
>> gfxTextRunFactory::Parameters::mContext. However, only a few things
>> from the gfxContext are used by the text run code:
>
> I was able to find a bunch of functions that only needed
> gfxContext::mRefCairo and so I've changed them to take a |cairo_t*|
> instead of a |gfxContext*|, which clears things up a bit:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1231550

I subsequently did something similar with all the other text/font
code, in the same bug. I'm on the fence about the usefulness of this
change.

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