Robert Sayre wrote:
On 10/16/05, James M Snell <[EMAIL PROTECTED]> wrote:
You still haven't answered the question about why nesting is *required*
I have code in front of me right now that is making a hierarchy by
building hashtables based on title attributes in link relations, based
on the unwritten spec that says servers must give the exact same title
to each collection they want to be grouped together.
Which unwritten spec is that? And what relevance does this have to my
question about nesting being *required*?
when I've already demonstrated an approach that will also work, is less
complicated, and is also supported by existing deployed software.
I have written an APP client using the approach you're advocating,
which is the status quo. I have also watched folks who have written
extremely good clients get tripped up by it. That's how I know the
approach is brittle and error-prone. The example below fails #1 from
Tim's test at the bottom of
<http://www.imc.org/atom-protocol/mail-archive/msg01967.html>.
How does it fail the test?
What Tim wrote: "Start with a single URI, get the “Introspection
Document”, find pointers to Entry and Media collections (HTTP GET)"
Start with a single URI: http://example.com/2nd_weblog
Get the Introspection document: <html><head><link ...></head>...</html>
Find points to Entry and Media collections: <link .. href="entries" />,
<link .. href="pics" />
Sure sounds like it meets the requirement to me. Perhaps you're seeing
something I'm not?
What it sounds like you're advocating is being able to find all of the
collections for multiple weblogs all at once. (the main blog and 2nd
blog). I'm advocating that it's far less complicated to do each one
separately... regardless of what the code you're currently looking at does.
- James
GET /2nd_weblog HTTP/1.1
Host: example.com
...returns
<html>
<head>
<link rel="collection" href="/entries" />
<link rel="collection" href="/pics" />
<link rel="collection" href="/categories" />
<link rel="collection" href="/foo" />
Robert Sayre
