Re: Intent to implement: Metrics API for FxOS data collection

[Frederik Braun]

This is going to be a certified API, right?

On 01.05.2015 23:43, Tamara Hills wrote:
> Hi All,
> 
> Summary: We want to expose a Web API to Gaia to collect metrics for FxOS.
> This API would leverage the existing Gecko toolkit/components/telemetry
> capabilities to provide histograms to Telemetry Servers for analysis by
> data owners.
> 
> Bug: 1160634
> 
> Link to standard: No formal specifications that I was able to find on W3C
> for this topic and I am not aware of any conversations with any other
> browser vendors.
> 
> Platform coverage: This would only be available on Firefox OS.  The plan
> right now is to only have this available to certified apps.  This may
> change in the future, but we would come back to the list if that happens.
> 
> Estimated or target release: We are looking to have an initial set of
> metrics exposed to FxOS by June 2015.
> 
> Preference behind which this will be implemented: Planning to use
> dom.telemetry-api.enabled
> 
> DevTools bug: 1160645
> 
> Thank you,
> 
> Tamara Hills
> ___
> 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: Intent to deprecate: Insecure HTTP

[Eric Shepherd]

Richard Barnes wrote:
Nobody right in the head is going to be plugging an antique with a 
1mhz processor directly into an unfiltered, internet-facing network 
connection, but I guess people who aren't right in the head like that 
are still people whose concerns deserve consideration. 
The SE/30 was 16 MHz, but it was also 32-bit, which makes a lot of 
difference as compared to an 8 or 16 bit machine when trying to do 
modern crypto. And I promise not to talk about retro gadgets anymore, 
since this is way off topic.


FWIW, I concede that I'm among those that misinterpreted the original 
email on this. That it's still going to be possible to do basic things 
is good to know.


I admit I'm a mite sensitive about the issue, because our little 
community of retro hackers has been working for a very long time (over 
twenty years now!) on bringing up TCP/IP stacks, getting newer and 
better network adapters designed and built, drivers written and 
optimized, etc. We finally get to the point where cool stuff is starting 
to really be feasible and this comes along. It was a little like driving 
your sled dog team through the worst blizzard in history to be the first 
person to the North Pole only to have someone steal your sled just 
before you get there. :)


--

Eric Shepherd
Senior Technical Writer
Mozilla 
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: What's the plan to implement UDP sockets in Worker?

[Eric Rescorla]

On Sun, May 3, 2015 at 5:30 PM, Josh Matthews  wrote:

> Adding worker support to the API does not imply changing any of the
> current restrictions on which content is allowed to make use of it.
>

Yes, I agree with that. I just misread the original post. Sorry about the
confusion

-Ekr



> Cheers,
> Josh
>
> On 2015-05-03 2:26 PM, Eric Rescorla wrote:
>
>> The difficulty is that this is not a safe piece of functionality to expose
>> to
>> unprivileged code.
>>
>> -Ekr
>>
>>
>> On Sat, May 2, 2015 at 8:03 PM, Josh Matthews 
>> wrote:
>>
>>  On 2015-05-02 10:33 AM, Yonggang Luo wrote:
>>>
>>>  I am looking into it.


  I have not been able to find any prior art on bugzilla, but my
>>> impression
>>> is that it is something we want.
>>>
>>> Cheers,
>>> Josh
>>>
>>> ___
>>> 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
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: What's the plan to implement UDP sockets in Worker?

[Josh Matthews]

Adding worker support to the API does not imply changing any of the 
current restrictions on which content is allowed to make use of it.


Cheers,
Josh

On 2015-05-03 2:26 PM, Eric Rescorla wrote:

The difficulty is that this is not a safe piece of functionality to expose
to
unprivileged code.

-Ekr


On Sat, May 2, 2015 at 8:03 PM, Josh Matthews  wrote:


On 2015-05-02 10:33 AM, Yonggang Luo wrote:


I am looking into it.



I have not been able to find any prior art on bugzilla, but my impression
is that it is something we want.

Cheers,
Josh

___
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: Using rust in Gecko. rust-url compatibility

[Valentin Gosu]

Thank you all for your suggestions. Asserting on differences sounds good,
and I think we can annotate the crash report with a sanitized URL as well
(replace all of the alfanumerical characters with x?). Also running a
crawler on top250 should iron out most kinks.

The plan is to land this preffed off, and only build the module if the rust
compiler is available on the system.
As Gregory pointed out, it would be better if the new implementation was as
close as possible as the current Gecko parser, so we avoid any regressions.
The main goal here is to make our parser safer with little behaviour
differences.

On 1 May 2015 at 20:58, Gregory Szorc  wrote:

> On Thu, Apr 30, 2015 at 3:34 PM, Valentin Gosu 
> wrote:
>
>> As some of you may know, Rust is approaching its 1.0 release in a couple
>> of
>> weeks. One of the major goals for Rust is using a rust library in Gecko.
>> The specific one I'm working at the moment is adding rust-url as a safer
>> alternative to nsStandardURL.
>>
>> This project is still in its infancy, but we're making good progress. A
>> WIP
>> patch is posted in bug 1151899, while infrastructure support for the rust
>> compiler is tracked in bug 1135640.
>>
>> One of the main problems in this endeavor is compatibility. It would be
>> best if this change wouldn't introduce any changes in the way we parse and
>> encode/decode URLs, however rust-url does differ a bit from Gecko's own
>> parser. While we can account for the differences we know of, there may be
>> a
>> lot of other cases we are not aware of. I propose using our volunteer base
>> in trying to find more of these differences by reporting them on Nightly.
>>
>> My patch currently uses printf to note when a parsing difference occurs,
>> or
>> when any of the getters (GetHost, GetPath, etc) returns a string that's
>> different from our native implementation. Printf might not be the best way
>> of logging these differences though. NSPR logging might work, or even
>> writing to a log file in the current directory.
>>
>> These differences are quite privacy sensitive, so an automatic reporting
>> tool probably wouldn't work. Has anyone done something like this before?
>> Would fuzzing be a good way of finding more cases?
>>
>> I'm waiting for any comments and suggestions you may have.
>> Thanks!
>>
>
> Shipping *any* Rust component as part of Gecko is already going to be a
> long and arduous task. I think it makes sense for the first Rust component
> in Gecko to be a drop-in, behavior identical replacement. i.e. don't bloat
> scope to include behavior changes that could jeopardize the deliverable. It
> would be really unfortunate if we did all this Rust preparation work only
> to have the feature utilizing it backed out because of behavior differences.
>
> But this is a very high-level observation. I know others spent a lot of
> time figuring out what to Rust-ify first and URL parsing was eventually
> chosen. If you say it is the least risky part of Gecko to swap out, I trust
> that assessment.
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

reminder: C++ mode lines

[Andrew McCreight]

I just landed a 1.2MB patch to fix C++ mode lines in dom/

As a reminder, the mode lines that should be used (in C++ files that are
properly 2-space indented) are:

/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2
-*- */
/* vim: set ts=8 sts=2 et sw=2 tw=80: */

See more at:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line

I generated the patch using a Python script, modeline.py, which can be
found on GitHub:
  https://github.com/amccreight/moz-source-tools

Feel free to use it for other directories, though I've already run it for
xpcom/. It tries to analyze whether a file is 2-space indented, which is a
little finicky.

Thanks to jst for reviewing the giant patch.

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

Re: What's the plan to implement UDP sockets in Worker?

[Eric Rescorla]

The difficulty is that this is not a safe piece of functionality to expose
to
unprivileged code.

-Ekr


On Sat, May 2, 2015 at 8:03 PM, Josh Matthews  wrote:

> On 2015-05-02 10:33 AM, Yonggang Luo wrote:
>
>> I am looking into it.
>>
>>
> I have not been able to find any prior art on bugzilla, but my impression
> is that it is something we want.
>
> Cheers,
> Josh
>
> ___
> 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: Intent to implement: Metrics API for FxOS data collection

[David Rajchenbach-Teller]

I like the idea. It would be interesting to see where a discussion with
other vendors could lead.

On 01/05/15 23:43, Tamara Hills wrote:
> Hi All,
> 
> Summary: We want to expose a Web API to Gaia to collect metrics for FxOS.
> This API would leverage the existing Gecko toolkit/components/telemetry
> capabilities to provide histograms to Telemetry Servers for analysis by
> data owners.



-- 
David Rajchenbach-Teller, PhD
 Performance Team, Mozilla



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform