Subject: Re: PaceIntrospection: Is another file format really needed?

From: [email-masked]
Date: 1 Jul 2004 15:35:34 -0000

--- [email-masked] wrote:
> What does the oh-so-limiting PaceIntrospection
stop you from doing, exactly?

You are putting words in my mouth. I never
referred to PaceIntroSpection as limiting. I only referred to your definition
of <feed> as "a frame of a pushed stream" as limiting and that this definition
is inconsistent with current practices, f.e. Atom API spec.

I agree, that
to move forward we first need to pin down the conceptual model of a feed,
because there is clearly some disagreement there.

But I do have an answer
to your question: "What does the PaceIntrospection stop you from doing, exactly?"

The proposed introspection format does not allow me to subscribe to the
introspection file containing my blog sites, with any of the current aggregators.
;-)

Peter

---

From: James Aylett <[email-masked]>
Date: Thu, 1 Jul 2004 17:02:06 +0100

> introspection file containing my blog sites, with any of the current aggregators.

I've only just read PaceIntrospection, because I didn't think it would
be that interesting or contentious, and I don't really have the right
background to contribute without thinking much (:-). But now I have
and I think that this entire argument is bogus, and due to
a misconception of what the introspection (at least as it was when
originally debated pre-IETF) was for.

You introspect a feed to find its service API points.

PaceIntrospection seems to want to provide a single file that allows
you to find out information about /several/ feeds in one go. In my
view that (a) shouldn't be called introspection; (b) shouldn't
actually happen. (It doesn't help that it reminds me a little of P3P,
which is always guaranteed to make me shudder.)

What's the problem with having each feed point to an introspection
file which lists its service API points (URIs)? We have a way of any
web page that is associated with the feed to point to the Atom feed;
then the feed points to the introspection file; that tells you how to
edit the feed (and perhaps the underlying resource group, depending on
what you're doing). It's disadvantage is mostly in the number of
requests required, but without bloating either the HTML page or the
Atom feed, that looks unavoidable.

If we want to roll up several feeds in one so people can easily keep
track of (for instance) the feeds a site publishes, that is a
different issue and should be addressed separately.

James

-- 
/--------------------------------------------------------------------------\
  James Aylett                                                  xapian.org
  [email-masked]                               uncertaintydivision.org

---

From: Robert Sayre <[email-masked]>
Date: Thu, 01 Jul 2004 12:25:23 -0400

James Aylett wrote:

>file which lists its service API points (URIs)? 
>

PaceIntrospection seems to be about "site" or "account" introspection.

Using your method, how would I find out where the endpoints are for my 
Typepad blinks, photo galleries, main blog, and template feeds are?

Robert Sayre

---

From: James Aylett <[email-masked]>
Date: Thu, 1 Jul 2004 17:33:33 +0100

> PaceIntrospection seems to be about "site" or "account" introspection.

Yes, which I don't understand the need for. Please enlighten me :-)
 
> Typepad blinks, photo galleries, main blog, and template feeds are?

I'd have thought you find them through the Typepad blinks, photo
gallery, main blog and so forth. It's likely I'm missing something
about how you need to operate (I have no idea what a template feed is
- I mean, I understand the words, but I don't know why you're rolling
templates into a feed) - is there a blow-by-blow description of what
job we want to do with this 'account introspection'?

Certainly I'd have thought that the photo gallery and the main blog
would have their own 'normal' URI presence, with (probably) HTML
behind it, or (if not) JPEG or something that we can embed RDF in via
XMP or whatever it is that Adobe are coming up with. Either way we can
link to the Atom feed as appropriate, which can link to the
introspection file so you can edit them.

For Typepad blinks, to be honest - I'm not sure. I'm not 100% clear
how the architecture is supposed to be viewed here. A blink feed is a
separate feed which happens to be aggregated into the display page of
another blog, right? In which case we maybe need to consider how to
express that at the HTML -> Atom feed stage.

But I'm probably wrong, of course :-)

James

---

From: Robert Sayre <[email-masked]>
Date: Thu, 01 Jul 2004 13:18:18 -0400

>Yes, which I don't understand the need for. Please enlighten me :-)

I think PaceIntrospection is a simple version of WSDL.  Look at it from 
a use case perspective:

1.) I sign up for typepad.com
2.) I try out the web interface, but decide I would rather use my slick 
OS X Cocoa authoring program
3.) Where can I point my program so that I don't have to enter 
everything individually?

I've never used WSDL for anything other than SOAP, so I don't know how 
fully baked its ReST description capabilities are [1].

This proposal would seem to offer an alternative approach.

Robert Sayre

[1] http://www.w3.org/TR/2003/WD-wsdl12-bindings-20030611/#_http

---

From: Joe Gregorio <[email-masked]>
Date: Thu, 1 Jul 2004 13:57:01 -0400

On Thu, 1 Jul 2004 17:02:06 +0100, James Aylett <[email-masked]> wrote:
> you to find out information about /several/ feeds in one go. 

It allows you to find the facets of several 'sites' at one time.

> In my  view that (a) shouldn't be called introspection; (b) shouldn't

Unfortunately it already does happen, at the end of the Pace it 
outlines where TypePad and Blogger *are already doing this*.
The solution *already deployed* has some ambiguity and this 
Pace is designed to remove that ambiguity and place this 
obviously needed functionality into the spec.

> different issue and should be addressed separately.

+1 

    -joe

---

From: "John Panzer" <[email-masked]>
Date: Thu, 1 Jul 2004 14:29:38 -0700

> > different issue and should be addressed separately.

I have a use case for combining the two:  AOL Journals lets a user 
create as many blogs as they want to; the main pages for these blogs are 
always under http://journals.aol.com/username/blogname.  We have to 
provide a standard way to provide a list of the blogs that's easily 
discoverable given the username.  This list is dynamic and can change 
from hour to hour, though usually it'd be pretty stable.  The contents 
of the list, in our case, can change depending on the _requestor_ of the 
list -- anonymous requests would get only public blogs, whereas 
authenticated users would get a list of both public blogs and private 
blogs to which the requestor has been granted access.

The data that a client would want includes an endpoint for getting a 
list of entries (the <feed>), a URI to the corresponding HTML page if 
one exists, and perhaps endpoints such as post, comment, etc. This 
enables software to offer status information (e.g., last post date), 
subscription, posting, commenting, etc. services.

It seems useful to me to combine the query-to-get-the-list with the 
query-to-get-the-endpoints, because they will in reality be combined for 
this use case.  It could save dozens of HTTP round trips to the server 
to gather all of the information, which could be a significant win in 
terms of latency.

We are wrestling with these issues right now for AOL Journals, so these 
are not just theoretical considerations.

Note that in this _particular_ use case, the 'introspection' file is 
really a dynamic feed-like-thing.  One could imagine, for example, 
software that lets you say 'let me know whenever Joe Gregorio creates a 
new blog!' and uses a feed-like mechanism for polling for this.  We'd 
want to re-use the Atom authentication mechanisms, polling time hinting, 
HTTP caching, etc. etc. for this data just as we would for an 
entry-based feed.  So I think there's some justification for treating it 
like a feed.

(There are other, more blue sky, use cases.  Consider a feed of 
endpoints for all new blogs created by people you know, whether or not 
you've ever subscribed to any of their blogs.)

John Panzer
http://journals.aol.com/panzerjohn/abstractioneer

---

From: Eric Scheid <[email-masked]>
Date: Fri, 02 Jul 2004 09:41:11 +1000

On 2/7/04 2:33 AM, "James Aylett" <[email-masked]> wrote:

> gallery, main blog and so forth.

so a site author, or contributor[1], would need to scour the entire website
just to retrieve account information? Even then, there might be some feeds
which do not have a direct front end presence such as a feed of
images/resources which get repurposed/referenced by entries in other feeds,
or are interface widgets like "quote of the day". Just because something
could have it's feed data exposed doesn't mean that it will, and I already
know of at least one site that withholds their blinks feed for members only,
no public access except via the website.

e.

[1] which is the stronger use case - invited contributors won't necessarily
have intimate knowledge of the site set up.

---

From: James Aylett <[email-masked]>
Date: Fri, 2 Jul 2004 13:33:03 +0100

> no public access except via the website.

Got it, thank you :-)

So if a feed pointed to an introspection file that listed facets for
several feeds, this requirement would be satisfied, yes?

I still don't see why anyone would want to squeeze this into the Atom
XML elements being used for the feeds themselves. There isn't a
semantic match there that I can see.

James

---

From: James Aylett <[email-masked]>
Date: Fri, 2 Jul 2004 13:51:39 +0100

> blogs to which the requestor has been granted access.

So this is for other people (users and non-users) to gain access to
blogs published by 'username'?
 
> subscription, posting, commenting, etc. services.

I understand why you want the feed URI and the HTML page URI. I'm not
sure I see why you need the comment facet given you surely can't
comment until you've read something to comment on - so you need to
fetch the feed or HTML page. Perhaps the comment facet should be in
the feed (particularly as it might be entry-specific)?
 
> this use case.

I'd have thought most users just needed the feed URI and HTML URI, and
nothing else. Do you have the ability to allow authenticated users to
post to some of your own blogs? So a tool would be pointed to
http://journals.aol.com/username/, would fetch the introspection file
(with possible authentication), and know all the blogs it can read
/or/ write to?

> entry-based feed.  So I think there's some justification for treating it 

I think /that/ is a good use-case for using an Atom feed file. But I
think it's very different from "give me the facets so I can edit <this
thing>". That's why I don't see the fit.
 
> you've ever subscribed to any of their blogs.)

Again, why do you need more than just the feed URI and HTML URI? At
most; if you're inside your happy aggregator world, you might not want
the HTML URI.

It's a cool idea, but I don't see why it applies to the introspection
needs.

James

---

From: [email-masked] (John Panzer)
Date: Fri, 02 Jul 2004 09:29:07 -0700

>blogs published by 'username'?
Yes, it's available for anyone to query but the results you get depend 
on who you are.

>the feed (particularly as it might be entry-specific)?
Sorry, strike "commenting" above; you're right, it needs an entry 
context.  I was thinking of feed-level endpoints only (including 
extensions which people might want to add).

>(with possible authentication), and know all the blogs it can read
Yes, exactly.  So in some cases you see a "post" button next to the blog 
name, in others you don't.

A specific use case here is where you're displaying a dashboard of all 
the blogs you own.

>thing>". That's why I don't see the fit.
Here's what I might want to see as a result of this feed-like-thing:

My Cat Picture Blog    [post]
My Other Blog    [post]
A Shared Community Blog  [post] (last updated: [Today])
My Friend's Blog   (last updated: [Today])
My Friend's Cat's Blog  (last updated: [5/1/04])

...with appropriate hyperlinks for each element.

(Actually, this is starting to look a little bit like a weird synthetic 
feed.  Except that this feed filters out the entries....)

>most; if you're inside your happy aggregator world, you might not want
The idea is to provide the feed-level information that a user agent 
might need.  This might include the post URI as described above, as well 
as extension URIs.  The reason for returning them all at once instead of 
having the user agent get just each feed URI in turn and then query 
_that_ to get the other URIs is because this could greatly increase 
latency (consider a list of 50 feeds).

If you need to return two URIs per feed, you might as well return N URIs 
per feed and allow for extensions.

>It's a cool idea, but I don't see why it applies to the introspection
I think that introspection is a bad term for this.  That is, 
introspection is a _part_ of these needs, but is not necessarily the 
primary issue.  But it is intertwined for the reasons given above.

-John Panzer