Re: [w3ctag/design-reviews] Incremental Font Transfer: Patch Subset (Issue #849)

> > Due to the complex nature of fonts a smart server is pretty much necessary to efficiently transfer all classes of fonts.
> 
> That causes me concern, because HTTP systems scale well when the server doesn't need to be particularly smart. If we _need_ to add complex processing to the server, it's best to make it as generic as possible so that it can be reused, enhancing the incentive to implement it (especially by actors like CDNs).
> 
> > We have invited experts from the fonts community that participate in the web fonts working group in addition to representation from font hosting providers (Google Fonts and Adobe).
> 
> Understood. I think you need engagment from people who serve HTTP at scale, not just font folks. It may be good to have a more detailed discussion about the design details here in the [HTTP WG](https://httpwg.org/) or the [HTTP Workshop](https://httpworkshop.org/), to give it visibility in those communities. I'm happy to help facilitate that if there's interest.

Yes, I'm definitely interested in engaging with those http groups. If you're able to help start those discussions that would be really helpful.

> 
> > Having this standardized and available in browsers should provide pretty good motivation for adoption by font hosters.
> 
> Perhaps. What comes to mind here is Apple's experience with HLS for live streaming. When they wanted to do low latency (LL-HLS), they specified use of HTTP Server Push because that's what they thought reasonable, and because it was supportable on their server, their clients, and those they consulted. However, when they tried to get adoption by CDNs and other parties, there was strong pushback, because Server Push isn't widely supported, has some definitional issues and gaps for use in that case with intermediaries, and generally wasn't useful for CDNs to implement except for this special case. So, after considerable consultation, Apple changed LL-HLS so that it was more compatible with that infrastructure.
> 
> I'm not necessarily saying that CDNs won't implement IFT as specified -- their various product teams would need to be looped in to make that call. However, this does feel very similar, from my perspective, and on the surface, the incentive to implement efficient streaming video is much stronger.
> 

Another avenue for adoption we’ve been thinking about would be to use edge compute that some CDN’s have available (for example Cloudflare workers). The IFT protocol is stateless so it should be a pretty good fit for that model. If there were an open source implementation of a worker it would be pretty easy for CDN users to plug in to provide IFT functionality for existing font assets.

> > The problem we’re solving is pretty specific to web fonts so the solution is specific to the space. HTTP range-request solves the more general problem of partially loading resources, but isn’t sufficient for web fonts. As noted above we are using an existing general purpose patching mechanism and only specializing where needed: in the message which describes the partial font subset.
> 
> Keep in mind that range requests themselves were originally for a very specific purpose: browsing PDFs without downloading the whole file.
> 
> I see some commonality between what you're doing and what the [Braid](https://www.braid.org) folks are attempting; have you talked to them? HTTP API folks might also have some complimentary use cases; see the [HTTP API WG](https://ietf-wg-httpapi.github.io), for example.

I do think it might still be possible to use range requests with a custom range unit, but I do have some concerns that I’ve mentioned in https://github.com/w3c/IFT/issues/119#issuecomment-1684616571. Primarily it looks like we’d have to be non-compliant with the range request specification in how we populate the “Content-Range” header in the response (maybe that’s fine w/ a custom range unit, definitely worth some more investigation).

Braid looks pretty interesting but I don’t think it's a good fit with what we’re doing. Compression dictionary transport is already a good fit for handling the delta encoding portion.


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/849#issuecomment-1692608433
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/849/1692608433@github.com>