Re: PaceIntrospection - A use case. (was Re: PaceIntrospection: Is another file format really needed?)

[jpanzer@xxxxxxx (John Panzer)]

James Aylett wrote:

On Thu, Jul 01, 2004 at 02:29:38PM -0700, John Panzer wrote:

  

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.
    

So this is for other people (users and non-users) to gain access to
blogs published by 'username'?
 
  

Yes, it's available for anyone to query but the results you get depend on who you are.

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.
    

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)?
 
  

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

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.
    

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?

  

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.

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.
    

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.
 
  

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

(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.)
    

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.

  

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

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