[
Lists Home |
Date Index |
Thread Index
]
Vehement is a fair word. I'm probably calmer than that
in person, but over the averages of my posts on 80/20
engineering, fair. We have to approach the web cautiously
because our customers do have issues the average web
application doesn't. That doesn't mean we don't use
web technology or XML. We definitely do and that is
increasing. We tend to deploy closed systems though.
http://biz.yahoo.com/bw/040316/165150_1.html
Not all content is equal or can be treated equally.
The question is, is the technology that supports it
reapplicable? What is at the heart of aggregation?
What else is it good for? Does the content matter?
On the other hand, even in my line of work, I can conceive
of some uses for aggregators. Notification systems work
similarly and those are highly valued in public safety for
routine messages and reports. A user subscribes for
notifications. Otherwise, reports are typically routed
based on roles, not subscriptions. They show up in a
notification window (a treeview much like Outlook) and
there are rules for responding, to whom, what can be done
to the content (eg, revising, annotating), who can do
it, and how long it can sit in a queue before it starts
pinging someone for attention. So a bit more than a blog,
but a form of aggregation as I understand it (which I might not).
Cheap and as reliable as it needs to be is ok. But then,
doesn't the RSS format itself become an issue? It is a
news format of sorts, not a reporting format for deeply
tagged information. The question I ask (because I really
don't pay much attention to RSS and blogs except to read
a few) is what properties of aggregation software are
attractive without RSS or Atom?
The term Tim used was 'syndication' so he is
likely thinking beyond blogging. I think in terms
of services. Is syndication a service?
len
From: Michael Champion [mailto:mc@xegesis.org]
Sorry if this is a bit off topic (now that we've actually been
discussing xml development for a change...)
'"I would like to have an RSS feed to my bank account, my credit card,
and my stock portfolio," he said.
"Anybody who has gone very far into this is starting to get very
excited," he said of the RSS phenomenon. "It's starting to feel like
1992 or 1993, when this Web thing was starting to stick its head out."'
Hmm, RSS feeds for credit card statements sounds more like a 1999
(internet bubble) idea than a 1992 (Web hitting critical mass) idea to
me. Let's think about why does RSS (all flavors, including Atom, and
including the infrastructure of HTTP and aggregators, not just the text
format) works so well to track news feeds and weblogs, then see what
that implies for bank accounts and credit cards:
- It hits the 80/20 point dead on. It's so simple you don't even need
agreement on much of anything except an approximate template for what a
news item looks like, and the news industry has evolved a pretty good
one over the years. Details about what to name tags, which date
formats to support, can be argued over forever, but all permutations
can be supported in code with relatively little trouble.
- It scales by exploiting the Web architecture and the power law
phenomenon. Popular feeds are cached in servers, intermediaries,
mirrors, etc. using exactly the same technologies used to support
popular websites.
- It ultimately contains human-readable text; all ambiguities about
what, where, when, why, how in the content or metadata are resolved by
the human reader.
- Father Darwin performs his brutal magic -- hacks that work evolve
into best practice, and ultimately (IETF willing) get standardized;
those that don't work die quietly.
Yep, that sounds a LOT like 1992 to me. It has created an
infrastructure of polling aggregators that has created a critical mass,
so lots of things that used to be done with mailing lists can now be
done quite nicely as RSS feeds to get information to interested parties
quickly and efficiently. The problem I have is in trying to make this
work as a universal pub-sub system: The things that make RSS et al a
winner for casual, public text make it a loser for critical, personal
data.
- 80% of the capability/reliability doesn't cut it. If I miss an news
flash about the latest horrors out of Iraq or Washington, or an update
to my favorite weblog, c'est la vie. If someone is draining my bank
account I want to *know* that reliably and immediately by a credible
and authoritative mechanism, not an 80/20 solution. (Given Len's line
of work, this is probably why he's so vehement about Mr. Pareto's
Principle).
- It's not going to scale if I'm the only consumer of a "feed." A bank
isn't going to appreciate having all their customers ping them every
few minutes to see if anything changed, and Bloglines won't help unless
there are lots of people subscribing to a given feed.
- It contains data, and the machine processing it will need to have
"intelligence" that is beyond the state of the art to resolve
ambiguities, or it had better match an authoritative standard that
stupid machines can easily map onto existing application semantics.
Anyone who thinks that there are likely to be authoritative standards
here doesn't follow the RSS 0.91 / 1.0 / 2.0 / Atom discussions, or the
somewhat more genteel standards warfare going on in the Web Services
community.
- Father Darwin (well his alter ego the Invisible Hand) will indeed
whack the un-successful, but not before a new generation of Enronesque
scammers and pill-purveying spammers do their worst. The consequences
of failure when real money and confidential information are at stake
are vastly worse than missing an update to a favorite weblog or the
latest horror stories from Iraq or Washington.
I'm all for leveraging XML and the Web out of the box for things that
it is well-suited for (and the current RSS ecology is one of them). I
get nervous when bubbles start inflating. In 20:20 hindsight, it was
obvious that the Web is a far better place to sell books and run
auctions than it is a place to sell petfood or groceries. I hope we can
apply some 20:20 foresight here and figure out an *appropriate*
combination of XML+HTTP, whichever Web services specs that actually do
something useful, and the real world enterprise infrastructure that can
be applied to the opportunities that Tim mentions.
|
