[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
> -----Original Message-----
> From: Henri Sivonen [mailto:hsivonen@xxxxxx]
> Sent: Saturday, December 06, 2003 3:13 AM
> To: Jeremy Gray
> Cc: 'Randy Charles Morin'; atom-syntax@xxxxxxx; 'Seairth Jacobs'
> Subject: Re: mota
> >> #1 A protocol that is entirely Web-based, in fact, let's call it
> >> strongly coupled to the Web. And #2 A protocol that decouples the
> >> content from the Web.
> >> I'd prefer #1, you'd prefer #2. iM starting to think that most prefer
> >> #2.
> >> Arg! Is that the consensus?
> > The success of syndication and aggregation applications and servies
> > would
> > suggest that #2 is clearly beating #1.
Allow me to re-add the context-giving statement you snipped when quoting me:
"To be clear: #1 being the classic
point-your-browser-at-a-web-site-at-a-time-and-start-clicking method, #2
quite likely involving HTTP and XML/XHTML but not being the "Web" in that
sense. I guess there's the web and then there's the web, eh? :)"
> I don't think the current situation means decoupling content from the
> Web is a superior or desirable choice compared to keeping the content
> on the Web.
Allow me to make a few things clear: The preference of #2 was _assigned_ to
me when #2 was invented, not stated by me after reading the options and
having a chance to clarify their meaning. Using the context-giving statement
that was included my post to define what I see as #1 vs. #2 in terms of
Atom, yes I do happen to prefer #2, and I have a perfectly good reason for
> There seems to be a tendency to solve problems by inventing new
> containers instead of solving the problems by refining the interior of
> what already exists.
> That is, when traditional browsers don't do
> polling, people make "desktop aggregators" that embed browser engines
> instead of adding polling capabilities to a browser. When HTML doesn't
> carry all the metadata that people want it to carry, an Atom Entry
> wrapper is invented instead of putting the metadata inside XHTML head.
This is all for a good reason: hundreds to thousands to millions of
installed aggregators don't want to be pulling full XHTML pages just to get
at the Atom content within.
This is not about some kind of mis-guided problem-solving tendency. This is
not about randomly re-ordering the layers that currently exist.
This is about _recognizing_ the layering of existing systems. This is about
then determining the correct layering for this application. This is about
leveraging as much pre-existing technology as possible, but without
sacrificing the needs of the application.
Perhaps I can help you see what is staring you in the face. It surprises and
disappoints me that so many people can miss what is so plainly obvious,
especially given the number of CMS applications that follow the exact model
I am about to use as the most obvious example.
There exists content. It may well be some form of HTML, for which there are
a number of available rendering engines. One application of this content is
to wrap it up in a browsable web UI for hosting on a web site, adorned with
headers and footers and menus and blogrolls and so on and so forth. CMS
applications consistently follow this layering model, whether they
pre-generate pages or do so dynamically:
In this usage model, content + web template => browsable web site => browser
Here comes Atom, giving new kinds of applications new ways to work with this
_content_. Ways that do not involve wrapping a template around it and
turning it into a web site. Ways that can leverage the existing layered
design, now doing the following in terms of aggregation:
Content => Atom application
Or, in the worst case, assuming the content is not natively stored in an
Content + Atom template => Atom application
Given that the content can be made directly accessable, why should Atom do
content + web template => browsable web site => Atom application
Atom doesn't need your web template, your browsable web site or any of the
trappings that come along with it, as the content can be accessed via a more
direct layering that results in less of an impedence mismatch, saves
bandwidth, enables new functionality, etc.
I present the following for your consideration:
It is you, sir, who are inventing a new container instead of refining and/or
layering on what already exists.