Re: [manifest] HTTP-based solution for loading manifests
On Wed, Dec 11, 2013, at 14:48, Marcos Caceres wrote: Would any potential implementer consider supporting a HTTP based solution to loading manifests? It seems quite premature to discuss a HTTP based solution to advertise a manifest. Even if it happens to be something developers ask for, we will anyway need to provide a link solution. It seems that the best course of actions we could take here is to implement the manifest feature using link and gather developer feedback to evaluate that alternative. Unless Jonas' concerns are that the manifest adoption could be strongly limited because of the lack of that feature? -- Mounir
Re: [manifest] HTTP-based solution for loading manifests
On 2013-12-11 13:13, Mounir Lamouri wrote: On Wed, Dec 11, 2013, at 14:48, Marcos Caceres wrote: Would any potential implementer consider supporting a HTTP based solution to loading manifests? It seems quite premature to discuss a HTTP based solution to advertise a manifest. Even if it happens to be something developers ask for, we will anyway need to provide a link solution. It seems that the best course of actions we could take here is to implement the manifest feature using link and gather developer feedback to evaluate that alternative. If you define a way using link, the alternative approach using the Link: header field essentially comes for free. ... Best regards, Julian
Re: [manifest] HTTP-based solution for loading manifests
On Wednesday, December 11, 2013, Julian Reschke wrote: On 2013-12-11 13:13, Mounir Lamouri wrote: On Wed, Dec 11, 2013, at 14:48, Marcos Caceres wrote: Would any potential implementer consider supporting a HTTP based solution to loading manifests? It seems quite premature to discuss a HTTP based solution to advertise a manifest. Even if it happens to be something developers ask for, we will anyway need to provide a link solution. It seems that the best course of actions we could take here is to implement the manifest feature using link and gather developer feedback to evaluate that alternative. If you define a way using link, the alternative approach using the Link: header field essentially comes for free. Mark seems to imply otherwise: for example, Mark says that [Link:] was never specified to be used with the stylesheet relation. https://github.com/w3c/manifest/issues/98#issuecomment-30293586 If that's the case, then neither would manifest? I also thought Link: was more or less generic. I should read the spec in detail. ... Best regards, Julian
Re: [manifest] HTTP-based solution for loading manifests
On 2013-12-11 19:59, Marcos Caceres wrote: On Wednesday, December 11, 2013, Julian Reschke wrote: On 2013-12-11 13:13, Mounir Lamouri wrote: On Wed, Dec 11, 2013, at 14:48, Marcos Caceres wrote: Would any potential implementer consider supporting a HTTP based solution to loading manifests? It seems quite premature to discuss a HTTP based solution to advertise a manifest. Even if it happens to be something developers ask for, we will anyway need to provide a link solution. It seems that the best course of actions we could take here is to implement the manifest feature using link and gather developer feedback to evaluate that alternative. If you define a way using link, the alternative approach using the Link: header field essentially comes for free. Mark seems to imply otherwise: for example, Mark says that [Link:] was never specified to be used with the stylesheet relation. https://github.com/w3c/manifest/issues/98#issuecomment-30293586 I see the comment but I have no idea what he's talking about. The spec is generic; and the IANA registry (http://www.iana.org/assignments/link-relations/link-relations.xhtml) has a stylesheet entry. Firefox implements this for CSS and XSLT, Opera (classic) did for CSS. If that's the case, then neither would manifest? I also thought Link: was more or less generic. I should read the spec in detail. It's totally generic. Best regards, Julian
Re: [manifest] HTTP-based solution for loading manifests
* Julian Reschke wrote: On 2013-12-11 19:59, Marcos Caceres wrote: https://github.com/w3c/manifest/issues/98#issuecomment-30293586 I see the comment but I have no idea what he's talking about. The spec is generic; and the IANA registry (http://www.iana.org/assignments/link-relations/link-relations.xhtml) has a stylesheet entry. Firefox implements this for CSS and XSLT, Opera (classic) did for CSS. It seems pretty clear to me that he is disagreeing with the argument made earlier in the ... erm, flat list of comments, that because some web browsers do not support `Link` for stylesheets, it should not be used for anything at all. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: [manifest] HTTP-based solution for loading manifests
RFC5988 defines a model for linking (context, relation, target), as well as the Link header as *one* possible way to convey those links. There are many other possible ways to convey links; e.g., HTML link, atom:link, scribbled on the side of a shoebox, the various JSON linking proposals, etc. It usually doesn't make sense to REQUIRE someone to process all links that they come across. For example, while it's possible to put a link in HTML link and a and lots of other things, expecting HTTP proxies and other intermediaries to process it is not wise, because they generally don't like to process the bits. OTOH it makes lots of sense for a particular application of linking that needs proxies to process them to use the Link header, as http://tools.ietf.org/html/draft-nottingham-linked-cache-inv-04 does. So, while the Link header is generic, and indeed link relations (whether it's stylesheet, manifest or something else) are also generic, a particular *application* of linking (e.g., should my browser load a manifest?) ought to specify what link serialisations it expects to be used, to improve the chances of interop. The ones chosen have a lot to do with how they're expected to be authored and consumed. Of course, it doesn't make much sense to prohibit other serialisations, because it might be useful for some people, and anyway that's not how the Web works. Cheers, On 12 Dec 2013, at 6:21 am, Julian Reschke julian.resc...@gmx.de wrote: On 2013-12-11 19:59, Marcos Caceres wrote: On Wednesday, December 11, 2013, Julian Reschke wrote: On 2013-12-11 13:13, Mounir Lamouri wrote: On Wed, Dec 11, 2013, at 14:48, Marcos Caceres wrote: Would any potential implementer consider supporting a HTTP based solution to loading manifests? It seems quite premature to discuss a HTTP based solution to advertise a manifest. Even if it happens to be something developers ask for, we will anyway need to provide a link solution. It seems that the best course of actions we could take here is to implement the manifest feature using link and gather developer feedback to evaluate that alternative. If you define a way using link, the alternative approach using the Link: header field essentially comes for free. Mark seems to imply otherwise: for example, Mark says that [Link:] was never specified to be used with the stylesheet relation. https://github.com/w3c/manifest/issues/98#issuecomment-30293586 I see the comment but I have no idea what he's talking about. The spec is generic; and the IANA registry (http://www.iana.org/assignments/link-relations/link-relations.xhtml) has a stylesheet entry. Firefox implements this for CSS and XSLT, Opera (classic) did for CSS. If that's the case, then neither would manifest? I also thought Link: was more or less generic. I should read the spec in detail. It's totally generic. Best regards, Julian -- Mark Nottingham http://www.mnot.net/
[manifest] HTTP-based solution for loading manifests
Would any potential implementer consider supporting a HTTP based solution to loading manifests? The rationale being: For manifests it is much more commonly going to be the case that there's existing content that people want to add a manifest to. Doing that by editing each and every HTML file or HTML-outputting server side script seems likely to in many cases be much harder than adding a config setting [on the server] that adds a link header. It would mean using something like the HTTP `Link:` header defined in [RCF5988] or a new HTTP header like `Manifest:`. So, something like the following in the case of [1]: Link: /manifest.json; rel=manifest Or the following in the case of a new header: Manifest: /manifest Please see the following for discussion: https://github.com/w3c/manifest/issues/98 [RFC5988] http://tools.ietf.org/html/rfc5988 -- Marcos Caceres
