- From: Ilya Grigorik <igrigorik@google.com>
- Date: Thu, 2 Apr 2015 14:06:01 -0700
- To: public-web-perf <public-web-perf@w3.org>
- Message-ID: <CADXXVKoZA-tVSCP2FbTxoQo8y3DGjv5_Bzwh6YeCg97-CbeoJA@mail.gmail.com>
Thinking about this some more, and with benefit of lots of great feedback from various folks... https://github.com/w3c/performance-timeline/pull/9#issuecomment-89042906 WDYT? Crazy talk? :) On Tue, Mar 24, 2015 at 2:26 PM, Ilya Grigorik <igrigorik@google.com> wrote: > On Fri, Mar 20, 2015 at 10:44 AM, Ilya Grigorik <igrigorik@google.com> > wrote: > >> ... and I believe that it's a generally useful and powerful concept that >> enables Performance Timeline to communicate event cascades. >> > > Just realized that the "cascades" part is not true. As currently proposed > an event cannot simultaneously be part of a group and have its own > subtree... For that we'd need two fields: "parent" to link to another event > or logical group, plus an "id" field that can act as a parent key for other > events. That said, I'm not sure if we need this extra functionality... It > seems that simple (one level) groups may be sufficient for the current use > cases? > > Some examples: > - Multi-req navigation: [nav-request{group: a}, redirected-req{group: a}] > - Multi-req resource fetch: [cors-request{group: b}, fetch-req{group: b}] > - Req + Server-Timing: [request{group: c}, server-timing{group: c}] > - Linking Frame-Timing events: [renderer{group: d}, composite{group: d}, > composite:{group: d}] > - ... > > Thoughts? Anything I'm forgetting or overlooking? >
Received on Thursday, 2 April 2015 21:07:09 UTC