Re: Proposed issue: site metadata hook

From: <Patrick.Stickler@nokia.com>
> >
> > From: ext Seairth Jacobs [mailto:seairth@seairth.com]
> >
> > I agree.  Repeating a post I made [1], you could use OPTIONS
> > to accomplish
> > such a thing.  No need for additional verbs.
>
> Well, what about MPUT and MDELETE (and likely MUPDATE)?
>
> So even if you could make it work the same as MGET, you'd
> only have part of the puzzle...

Not if you return a URI to a conventional resource that you can then use
GET, DELETE, etc. on just like any other resource.  Then there is no need
for additional verbs that perform the same function.  At the same time,
doing an OPTIONS on the returned URI could return yet another URI, etc.
This takes care of the meta-metadata bit.

> > However, these approaches require at least two hits on the
> > server.  While
> > this may be fine for favico or P3P (from the client
> > perspective), I wonder
> > if you will be able to convince crawlers, bots, etc. to give up the
> > robots.txt file.  From their perspective, any of these solutions would
> > double the amount of time it would take to do their job.
>
> MGET wouldn't. One single call to the server based on the site URI
> (<scheme>://<authority> portion).

I don't see how you can perform only one access with this method unless all
possible metadata is returned within the single response or you are using
some form of conneg.  In the first case, this means you would potentially
have a large entity when you only wanted a fraction of it (e.g. get the
equivalent of the favico out of a collection of robot rules, p3p documents,
etc.)  Otherwise, the returned entity would likely contain a pointer to the
resource of interest (favico, robots.txt, etc.).  As a result, it would have
to process the returned entity to find the appropriate pointer, then turn
around and make a second request to the server for that URI.

Or maybe I'm just not understanding how MGET would work.

> > Would it be possible to use OPTIONS along with a new series of
> > content-types?  For instance, suppose there was a
> > "metadata/favico" and
> > "metadata/robots".
>
> Preferably not.

I didn't say it would be pretty.  :)  But such an approach does have some
advantages...

---
Seairth Jacobs
seairth@seairth.com

Received on Tuesday, 11 February 2003 11:37:35 UTC