RE: Proposed issue: site metadata hook (slight variation)

 
> But, again, this imposes two system calls to get descriptions
> of resources *and* requires the explicit naming of those
> bodies of knowledge, which is unnecessary.

I don't see the two system calls as being particularly problematic since
in the general case, "metadata" resources would be requested orders of 
magnitude less often than "normal" resources. If use cases could be 
described where it was an issue I'd be interested in seeing them.

I also don't see why you *wouldn't* want to make the metadata, in any 
form, an addressable resource.  Its axiomatic of the web that important
information should have URIs.  Then the need for a parallel universe
of methods goes away.
 
> >     The meta-meta issue isn't a problem if OPTIONS returns a
> > Meta-Location:
> >     header to another resource. 
> 
> The meta-meta issue isn't a problem, period. For any of the
> proposals put forth in this thread.
> 
> My hope is that the answer to this question can still be 'yes'...
> 
> > > 2. Can the Meta-Location: tag be optional, if the server 
> > > owner does not care to name that body of knowledge explicitly?
> > 
> >    I would think it would have to be.  Fielding took issue with that
> >    header always being there in a message to rest-discuss [2].  This
> >    would really only be an issue if you tried to ride along with the
> >    GET response though; OPTIONS response wouldn't be as frequent.
> 
> I'll take this as a vote for 'yes'.

I take issue with the original premise the that metadata should 
ever be non-addressible.

Received on Wednesday, 12 February 2003 10:01:49 UTC