[webkit-dev] OUTAGE: Bugzilla not sending emails properly

[Brian Burg]

Hi all,

We’ve been getting reports that Bugzilla has not sent any mail out in the past 
24 hours. :-(
The server admins are investigating what’s up and will send out an email when 
it’s fixed.

-Brian
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev]

[Alexey Proskuryakov]

Hello Yoav,

Is there any technology on the horizon that would simplify doing this kind of 
optimization? If done manually, this seems:
- complicated, so only a few sites will do this;
- very likely to go stale, as the content changes, but preload instructions do 
not get updated;
- related to the above, the failure mode is opaque, as the website will only 
get a little slower to load, and not break functionally.

Sending the preload requests in HTTP response headers seems like it would 
provide the most benefit, but is also more prone to the above issues.

Preloading resources as untyped data doesn't seem like a good match to the 
loader implementation mostly dealing with typed resources. Additionally, 
fetching depends on the referring document's properties (notably the charset is 
inherited for same origin subresources). This is not necessarily a blocker, but 
the proposal adds a different way to think about subresource loading.

There appears to be some feature duplication with HTTP/2 server push 
functionality, could you please characterize the differences that would make it 
worth having both?

- Alexey


> 11 нояб. 2015 г., в 6:11, Yoav Weiss  написал(а):
> 
> Hi,
> 
> I'm interested in adding support for  
>  and the corresponding "Link:" headers and 
> wanted to gauge interest for supporting the feature.
> 
> The preload relationship provides a declarative fetch primitive that enables 
> developers to initiate a resource fetch and separate fetching from resource 
> execution. As such, preload is a low-level primitive that enables 
> applications to build custom resource loading and execution behaviors without 
> hiding resources from the user agent and incurring delayed resource fetching 
> penalties. 
> 
> Use cases include:
> * Early fetch of lately discovered critical resources - Sites that contain 
> critical resources that aren't discoverable by the preload scanner (e.g. 
> fonts, JS loaded scripts and styles, etc) can use the feature to download 
> these critical resources early
> * Separation of download and execution in a declarative, non-hacky way.
> 
> All in all, it would enable Web sites to significantly improve loading 
> performance in various common scenarios.
> 
> Thanks!
> Yoav
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] OUTAGE: Bugzilla not sending emails properly

[Brian Burg]

After some debugging and fixing, Bugzilla email seems to be working again. We 
apologize for the disruption!

> On Nov 17, 2015, at 10:07 AM, Brian Burg  wrote:
> 
> Hi all,
> 
> We’ve been getting reports that Bugzilla has not sent any mail out in the 
> past 24 hours. :-(
> The server admins are investigating what’s up and will send out an email when 
> it’s fixed.
> 
>   -Brian
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev