[dev-servo] Fwd: Progressive Web Metrics (PWM) in Gecko

[Till Schneidereit]

Forwarding to dev-servo; seems like adding these metrics might be
interesting to have useful comparisons between servo and other engines.

-- Forwarded message --
From: Dominik Strohmeier 
Date: Mon, Sep 26, 2016 at 3:46 PM
Subject: Progressive Web Metrics (PWM) in Gecko
To: dev-platf...@lists.mozilla.org


Greetings,

in an effort to enable a modern user-centric metrics suite that will allow
us to track measurements that represent the user perceived performance, we
aim to get Progressive Web Metrics (PWM) into Gecko
 (meta bug 1298380
). Beyond improving
our measurements around responsiveness of Gecko, PWM is also meant to
provide developers better performance measurements in the future.

The current efforts around PWM have mainly been driven by the Chromium team
that worked on drafting first specs for measurements and probes. There is a
presentation from Paul Irish here: bit.ly/pwmetricsdeck. Shubhie Panicker
is working on the spec for W3C Web Perf WG.

From a user's point of view, we see four key moments of experience when a
user intends to explore a new web page/app (adopted from here

):

   - *Time to First Meaningful Paint (TTFMP)
   :
   "Is it happening and useful?"* This first part is focusing on measuring
   from a user's perspective if navigation started successfully (the server
   has responded and if the page painted enough critical content that I
could
   engage with it? Technically, TTFMP measures the time from navigation
start
   to the first paint where page’s primary content is visible. Currently it
is
   defined as the the paint that follows the most significant layout
   .
   TTFMP is tracked in bug 1299117
   .
   - *Time to Interaction (TTIx): "Is it working?"* This probe will track
   when users start interacting with pages after navigation via click, touch
   or scroll event. During user research from the UX team, we have learned
   that users use scrolling to test if a page is fully loaded. In other
words,
   user interaction with new content marks the end of the user-perceived
page
   load process and defines the transition to interaction and content
   exploration.
   - *Time to Interactive (TTI)
   : “is it usable?"* This
   defines the transition from page load to ready for user interaction from
   the engine's point of view. TTI celebrates that the thread executing
   javascript is available enough to handle user input. In the current spec
   for TTI, there should be nothing blocking the render process for more
than
   50ms to handle input within a 10sec window. Further discussion on TTI
   calculation can be also found here
   .
   TTI is tracked in bug bug 1299118
   .
   - *Interaction probes: "Is it delightful?"*  Beyond page load, these
   probes track the responsiveness of the engine during users' content
   exploration/browsing.
  - *Estimated Input Latency (EIL)
  
  *aka Risk to Responsiveness (see bug 1303296
  ): Given that
  user input can happen anytime, EIL estimates the input latency
for new user
  input.
  - *Actual Input Latency: *Input latency starts at the event timestamp
  and measures time to glass. In Telemetry, this is currently tracked
  via INPUT_EVENT_RESPONSE_MS
  - *Frame Throughput*
  
  aka Jank-free scrolling and animation (see Chromium working draft
  
  and bug 1303313 
  ).

We are seeking engineering input and hope to get a discussion started here
about specs and implementation.
Thanks,
Harald and Dominik

--
Dominik Strohmeier | Staff Product Manager, Platform Metrics | Mozilla
___
dev-platform mailing list
dev-platf...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Proposal: TLS library for Servo

[Olaf Buddenhagen]

Hi,

On Thu, Sep 22, 2016 at 06:53:47PM -1000, Brian Smith wrote:
> Olaf Buddenhagen  wrote:

> > Sorry for being late to this discussion, but I feel the need to remind
> > everyone of the infamous OpenSSL licensing problem, i.e. the fact that
> > the SSLeay license it is (partially) covered by is considered
> > GPL-incompatible by many -- including (among others) the Debian project.
> > This affects not only OpenSSL itself, but also all forks, including
> > *ring* AIUI.
[...]
> Insofar as Debian is concerned, they figured out a way to ship OpenSSL.

Shipping OpenSSL itself is not the problem. Shipping any program using
GPL code linked against OpenSSL is. Debian doesn't do that: all GPL
programs are built against GnuTLS instead. (Either natively, or using
the wrapper provided with GnuTLS.)

While I singled out Debian, because I'm best familiar with the situation
there, this issue is really not limited to Debian at all. Folks from
Fedora for example, when they contemplated consolidating on a single SSL
implementation a few years back, proposed using NSS, precisely because
it doesn't have the licensing issue (while providing good OpenSSL
compatibility).

Note that the only reason why the issue is even disputed at all is that
the GPL has an excemption for libraries shipped with the operating
system, which is often deemed true for OpenSSL itself -- but it's
certainly not true for any Rust library using OpenSSL code...

> AFAIU, there is very little SSLeay-licensed code in *ring*. None of it
> seems irreplaceable and actually it seems desirable to replace most or all
> of it with Rust code under the ISC license anyway.

That would be great :-) But unless and until that actually happens, it
has to be considered hand waving...

Unfortunately, my mention of the SSLeay license has been misleading:
actually the original SSLeay license and the OpenSSL license used for
newer code *both* come with the problematic advertising clause, i.e.
*all* OpenSSL code is GPL-incompatible.

Also note that "replacing with Rust code" might or might not be good
enough, depending on what it means exactly. Just translating the old
code to a different language bit-by-bit does *not* obsolete the original
copyright -- only rewriting it from scratch without regard to the
original code does... Though the exact dividing line is a bit of a grey
area I think.

> > In view of this, I believe anything directly or indirectly based on
> > OpenSSL and its derivates cannot be considered a viable option.
>
> Rather than disqualifying things based on non-technical criteria, let's
> focus on technical criteria and then see what we can do to fix the
> non-technical stuff. The nature of software is that it is malleable;
> generally a problem today isn't a problem tomorrow if we're willing to do
> work to solve it.

I can't agree with this view. Technical problems can be solved --
legal issues are way more fundamental.

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

Re: [dev-servo] Weekly status updates

[Olaf Buddenhagen]

Hi,

As a spare time outside contributor, it has become pretty much
impossible for me to stay informed of what's happening in Servo land,
since the meetings (and thus the meeting notes) have been cancelled;
while few things are going over the mailing list; and the traffic on IRC
is impossible to keep up with for anyone but full-time contributors.

I have been reading the status updates for a while, but ultimately gave
up on it, because many developers do not update them (regularily) at
all; while some others provide a detailed changelog rather than a
higher-level overview, making it very boring to read; and also, these
updates mostly just tell what happened in the past, not what's brewing
right now...

Summing up, some way to stay in touch with ongoing/upcoming developments
would be great -- but I'm not sure the status updates in their present
form are very helpful in this regard.

TWiS is somewhat useful with its nice high-level changelog -- but again,
nothing about stuff in the works...

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

Re: [dev-servo] Weekly status updates

[Lars Bergstrom]

On Mon, Sep 26, 2016 at 12:36 PM, Olaf Buddenhagen
 wrote:
> As a spare time outside contributor, it has become pretty much
> impossible for me to stay informed of what's happening in Servo land,
> since the meetings (and thus the meeting notes) have been cancelled;
> while few things are going over the mailing list; and the traffic on IRC
> is impossible to keep up with for anyone but full-time contributors.
>
> I have been reading the status updates for a while, but ultimately gave
> up on it, because many developers do not update them (regularily) at
> all; while some others provide a detailed changelog rather than a
> higher-level overview, making it very boring to read; and also, these
> updates mostly just tell what happened in the past, not what's brewing
> right now...
>
> Summing up, some way to stay in touch with ongoing/upcoming developments
> would be great -- but I'm not sure the status updates in their present
> form are very helpful in this regard.
>
> TWiS is somewhat useful with its nice high-level changelog -- but again,
> nothing about stuff in the works...

Thanks for the feedback! This is something I care a lot about. Are you
saying that you'd like to see something between
https://github.com/servo/servo/wiki/Roadmap, which gives what people
are working on for the rest of the quarter, and the "next week"
section of the status reporting?

Or are you saying that part of the problem is that we're not really
capturing the "next week" details well enough so that, e.g., you know
that Vlad's going to be looking into ipc-channel Windows support and
might need your feedback?
- Lars

BTW, I am full-time and I can't keep up with the IRC channel either.
And I (we) shouldn't! If IRC becomes a substitute for GitHub issues
and the mailing list, then it will crowd out both volunteers and
contributors who are not in the "right" timezone. I try to make sure
that people don't make *decisions* on IRC, as that's a pretty nasty
community anti-pattern, but I'm sure I've done it myself and should
definitely be called out when I do that.
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo