Re: [whatwg] More effective model for handling resources

[Lewis Dexter Litanzios / ldexterldesign]

"Throughout the process, the core developers of SPDY have been involved 
in the development of HTTP/2, including both Mike Belshe and Roberto 
Peon. As of February 2015, Google has announced that following the 
recent final ratification of the HTTP/2 standard, support for SPDY would 
be deprecated, and that support for SPDY will be withdrawn completely in 
2016.[7]" - https://en.wikipedia.org/wiki/SPDY


Regards

On 03/04/2014 06:37, Tingan Ho wrote:

Hi Ian,

I believe this is being handled by the next-generation transport protocols

(SPDY or whatever it's called now). I recommend approaching the relevant
groups to check that your precise case has been handled.


I just found out that SPDY Server Push and Cookies could accomplish the
above mentioned caching. Cookies will take care of information providing.
And the server just uses Server Push to push content.


On Thu, Apr 3, 2014 at 1:57 AM, Ian Hickson  wrote:


On Thu, 13 Mar 2014, Tingan Ho wrote:

Almost all web developer I know use externally linked CSS resource in
their web projects. That means that the browser needs to (1) request the
html page (2) parse the html (3) request for the CSS resource that is
linked from the html document. The problem with externally linked
resources is point three. It needs to make another request for the CSS
resource. There is a solution to this problem and that is to inline the
CSS. Though that would yield another problem: all subsequent page
request will become bigger.

I believe this is being handled by the next-generation transport protocols
(SPDY or whatever it's called now). I recommend approaching the relevant
groups to check that your precise case has been handled.

--
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'






--
ldexterldesign ldexterldesign 
Lewis Dexter Litanzios
User Experience Designer
+44 7504 907 304

Re: [whatwg] More effective model for handling resources

[Tingan Ho]

Hi Ian,

I believe this is being handled by the next-generation transport protocols
> (SPDY or whatever it's called now). I recommend approaching the relevant
> groups to check that your precise case has been handled.


I just found out that SPDY Server Push and Cookies could accomplish the
above mentioned caching. Cookies will take care of information providing.
And the server just uses Server Push to push content.


On Thu, Apr 3, 2014 at 1:57 AM, Ian Hickson  wrote:

> On Thu, 13 Mar 2014, Tingan Ho wrote:
> >
> > Almost all web developer I know use externally linked CSS resource in
> > their web projects. That means that the browser needs to (1) request the
> > html page (2) parse the html (3) request for the CSS resource that is
> > linked from the html document. The problem with externally linked
> > resources is point three. It needs to make another request for the CSS
> > resource. There is a solution to this problem and that is to inline the
> > CSS. Though that would yield another problem: all subsequent page
> > request will become bigger.
>
> I believe this is being handled by the next-generation transport protocols
> (SPDY or whatever it's called now). I recommend approaching the relevant
> groups to check that your precise case has been handled.
>
> --
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>



-- 
Sincerely,

Tingan Ho

Re: [whatwg] More effective model for handling resources

[Ian Hickson]

On Thu, 13 Mar 2014, Tingan Ho wrote:
> 
> Almost all web developer I know use externally linked CSS resource in 
> their web projects. That means that the browser needs to (1) request the 
> html page (2) parse the html (3) request for the CSS resource that is 
> linked from the html document. The problem with externally linked 
> resources is point three. It needs to make another request for the CSS 
> resource. There is a solution to this problem and that is to inline the 
> CSS. Though that would yield another problem: all subsequent page 
> request will become bigger.

I believe this is being handled by the next-generation transport protocols 
(SPDY or whatever it's called now). I recommend approaching the relevant 
groups to check that your precise case has been handled.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] More effective model for handling resources

[Tingan Ho]

>
> (Ideally, by the way, we would bake cache expiration and any other
> relevant response header metadata into the archive format. Of course,
> this puts the onus on the browser to decide whether to send a separate
> request for a particular resource in case it has changed, not on the
> server to know and supply the new version - but I think this is a
> better way to do things, personally.)


I'm not sure I understand fully what you mean. I guess the suggested
solution is an archive format? In most/all cache solution the server needs
to handle etag and invalidate caches.  The client could handle the expires,
which the suggested solution does.


On Fri, Mar 14, 2014 at 3:39 AM, Qebui Nehebkau <
qebui.nehebkau+wha...@gmail.com> wrote:

> On Thu, Mar 13, 2014 at 6:57 AM, Tingan Ho  wrote:
> > Thought and feedback is welcomed
>
> Surely it would be better to send an archive file containing the
> resources the server expects the client to need, employing the Accept
> header to decide whether to do so (ie, in order to request only the
> lone file without whatever else the server feels should go along, the
> client should exclude archives from the acceptable types), &c.?
>
> I suppose it is possible that some intermediate caches may handle this
> poorly, but, if so, that's fundamentally just bad design on the part
> of those caches; I really think we just have to accept it and do the
> sensible thing anyway.
>
> (Ideally, by the way, we would bake cache expiration and any other
> relevant response header metadata into the archive format. Of course,
> this puts the onus on the browser to decide whether to send a separate
> request for a particular resource in case it has changed, not on the
> server to know and supply the new version - but I think this is a
> better way to do things, personally.)
>



-- 
Sincerely,

Tingan Ho

Re: [whatwg] More effective model for handling resources

[Qebui Nehebkau]

On Thu, Mar 13, 2014 at 6:57 AM, Tingan Ho  wrote:
> Thought and feedback is welcomed

Surely it would be better to send an archive file containing the
resources the server expects the client to need, employing the Accept
header to decide whether to do so (ie, in order to request only the
lone file without whatever else the server feels should go along, the
client should exclude archives from the acceptable types), &c.?

I suppose it is possible that some intermediate caches may handle this
poorly, but, if so, that's fundamentally just bad design on the part
of those caches; I really think we just have to accept it and do the
sensible thing anyway.

(Ideally, by the way, we would bake cache expiration and any other
relevant response header metadata into the archive format. Of course,
this puts the onus on the browser to decide whether to send a separate
request for a particular resource in case it has changed, not on the
server to know and supply the new version - but I think this is a
better way to do things, personally.)