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