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.

> 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.

> 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.



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

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