Re: Blogging needs a whole new BAG...

[Tim Bray <Tim.Bray@xxxxxxx>]

On May 18, 2004, at 9:57 AM, Bob Wyman wrote:

>     Just as "the web" has a TAG (Technical Architecture Group) I think 
> Blogging needs a BAG (Blogging Architecture Group.) I believe that the 
> charter for either the W3C or IETF Atom group should include a task to 
> form a BAG and produce a Blogging Architecture.

I disagree entirely.  First, we get Atom right, designing a tool that 
does a small number of jobs well.  I frankly have not the slightest 
hope of getting consensus on what the Blogging Architecture is without 
some more experience.

If any standards organization were to suggest that the completion of 
the short-term Atom work should be tied to the boiling of the 
blogging-architecture ocean, I would strongly recommend we avoid going 
to that organization.

>     * Push vs. Pull: Currently, blogging is all about pull and 
> polling. However, it is clear to many that the current approach simply 
> won't scale.

I think there's a good chance it'll scale just fine.  I expect that at 
some point, very popular feeds are going to have to put some sort of 
specialist polling aggregator between them and their millions of 
subscribers, just as big websites use Akamai or other caching/staging 
engines.  Nothing in the design of RSS or Atom gets in the way.  Trying 
to solve the problem in advance is premature optimization.

>     Clearly, we need to consider providing real "publish/subscribe" 
> support for blogging and thus for Atom data. We need to deal with the 
> question of "Push" not "Pull."

I disagree. See, you are going to have a real problem getting consensus.

>  Will W3C be willing to support push-based Atom?

First, prove that push-based Atom (a) works, (b) interoperates, and (c) 
meets a real need.  Then, standardize it.

>      * Pinging: Blogging benefits from the various "pinging protocols" 
> which currently depend on XML-RPC (a non-W3C protocol).

Not true.  I ping weblogs.com, blo.gs, and technorati by clicking on a 
bookmarklet.  I agree that this area needs serious work, but first of 
all it needs more engineering experimentation to figure out the right 
solution before you turn it over to a committee.

>     * Trackback: The "trackback protocol" is popular, provides 
> benefit, etc.

And is still experimental, and its rate of uptake seems to have stalled.

>     Trackback is a generally useful function that should be supported 
> outside the realm of blogging. A major "architectural" issue with the 
> web has always been the fact that links are uni-directional. Explicit 
> trackbacks are one way of providing the backlinks needed to construct 
> bi-directional links. Presumably, bi-directional links would be 
> generally useful. What, if any, modifications would need to be made to 
> trackback in order to make the facility generally useful? Are there 
> extensions to HTML that should be made in order to record "in-bound" 
> links or to provide a means of pointing to where one would discover 
> in-bound links?

Having burned two years of my life trying to advance the state of the 
art in hyperlinking on the XLink working group, I am profoundly 
unwilling to tie the progress of Atom in any way to this set of issues.

>      * OPML: Many blogging applications rely on OPML files as a means 
> of recording and exchanging lists of blogs, metadata about them, etc. 
> There is not, however, a well-accepted definition of how one builds an 
> OPML file

Here, you have a point.  On two separate occasions I've asked an 
engineering group to use OPML for something or other and they came 
back, baffled, saying "but there's no there there, you can stick 
anything in, it'll never interoperate."  So I agree that work on this 
one might be fruitful.  But Atom doesn't need to wait for it.

>     * HTTP has limitations that are a true burden in blogging. For 
> instance, there is no server-side support for identifying and 
> retrieving of "fragments" of a resource served by an HTTP server. 
> Thus, you can't say things like "Give me only the entries that have 
> been updated since time XXXX'". Should HTTP be extended to address 
> better the needs of Atom? Should RFC-3229 be extended to define an 
> ATOM specific mechanism for retrieving Atom Fragments?

Well, you could indeed, for most CMSes, create a URI that would launch 
a query that would retrieve a bunch of entries, or an RSS/Atom feed for 
them, or whatever.  There might be scope for standardizing the query 
encoding.  But please, please don't try to redesign HTTP, let's keep 
our layering clean.

I could go on, but I'll stop.

I think the Atom community should proceed apace with the work of 
designing a feed format and publishing protocol, standardizing the 
current well-understood best engineering practices in this area, and do 
it as quickly as possible.  By the time we're finished, the next set of 
problems that needs solving will be more apparent.

 -Tim