proposal for capabilities lookup

Mon Nov 21 11:28:33 PST 2005

Martin Atkins <mart <at> degeneration.co.uk> writes:

> 
> Michael Graves wrote:
> > 
> > The interesting thing here is that orienting things toward static file 
> > semantics ( GET "yadis.xml" vs. CGI call) does *not* hinder the service 
> > provider from serving static file requests with dynamic responses. In other 
> > words, this URL:
> > 
> > http://idserver.net/mgraves/yadis.xml
> > 
> > is *ostensibly* a static file on the server, but with straightforward 
changes 
> > to the Apache configuration, this same URL can be served from a database or 
> > other resource, rather than just feeding back a static file. "yadis.xml" 
may 
> > not exist as a discrete file on any user's home directory for a given 
service 
> > provider. It may just be synthesized on demand and spit back as the 
> > appropriate file by Apache.
> > 
> 
> I keep rambling about CMSes that don't work from static files. Allow me
> to briefly describe the behavior of one in particular that won't work
> with your proposed scheme.
> 
> The CMS takes over the entire URL-space for a given domain, with two
> exceptions:
> * A particular "subdirectory" (as in, a prefix ending in a slash) is set
> aside for static files the user has uploaded. Usually these are PDF
> documents, images and the like.
> * Each site template (or "skin") has its own media directory which is a
> filesystem directory mapped into the URLspace for such things as
> stylesheets and images.
> 
> Users have no access to put "files" anywhere except in these two
> directories. They can, however, alter their site templates. This means
> that they can add anything they like into the HEAD section of the
> generated HTML, assuming that they don't mind it being there on every page.
> 
> For the rest of the site, the system uses URLs like:
> /About+Me/Contact+Me/email/
> These always end with a trailing slash. The system splits this up at the
> slashes and then recursively resolves the URL "parts" one by one through
> a set of lookup tables and eventually figures out what page to display
> from the database.
> 
> It's not possible for users to create non-HTML documents here. It's also
> not possible to create a "file" called yadis.xml, because that does not
> end in a trailing slash.
> 
> This kind of thinking might well seem off-the-wall at this point, but
> this does seem to be the way things are heading. With hosted weblog
> services (LiveJournal being an example) and systems which provide users
> with what is essentially a CMS into which they can inject their own
> content (MySpace? I'm not sure, I've never actually used it), sites
> based on static files are going to become less common. It's silly to
> depend on it.
> 
> 

Martin,

No doubt about, there *are* and *will be* sites and systems out there that 
thwart all attempts to manage files on the server by the user. This is a good 
thing, and part of what I'm taking into account. In the case you describe 
above, or for myspace.com for example, the only way YADIS gets integrated is if 
they allow for customizing some HTML by users. If a myspace.com user can just 
get the appropriate <link> tags in the <head> section, then the user can 
probably be YADIS-powered. Note that in this case, myspace.com would *not* 
allow for the creation of a resident file like "yadis.xml". So if the user can 
insert the <link> tags in their HTML, it won't help them to simply refer to a 
nother local file "yadis.xml" to declare their capabilities, because myspace 
won't let them create/store the file. In this case, the capabilities URL would 
have to be somewhere else - not in myspace.com -- and probably somewhere on the 
ID server for the user. 

I'll agree to this, though. If you can't edit any metadata in the CMS for your 
account, and your CMS doesn't want to support YADIS, you're likely SOL. :-)

This brings up an interesting point though. You mentioned that *every* page 
would be equipped with the appropriate <link> tags in your scenario. That's 
fine, but it has the effect of making *every* URL that is yours in the CMS in 
question effectively a *YADIS ID*, at least as we understand the term now. 

What we're really describing here is not the configuration of a URL as a YADIS 
ID itself, but a *claim* on a URL owned by a YADIS ID.  If you put <link> info 
in your HTML header template, resulting in every page on your CMS being YADIS-
enabled (i.e. discoverable), you're not setting up a whole set of IDs, but 
rather a set of pointers to a canonical ID. What makes a canonical ID canon? 
Good question. My initial reactions is that a canonical YADIS ID is one that 
defines and expresses capabilities and configuration parameters.

Gotta think about that some more...

-Mike