Re: XML protocol comparison

Hmmm interesting.

It totally makes sense that ICE would be used to distribute stories for
media other than the web, but I'm not interested in any media other than the
web. Any complexity that's added for the sake of other media that limits
accessibility to small non-corporate publishers is going to beget a simpler
protocol, which of course already exists, it's called RSS.

Further, authors who don't have their own websites need not be left out! The
barriers to having an individual website are coming way down. The tools are
better applied to making that easy, imho, to decentralizing the web, which
of course started out as a very decentralized medium.

Another question -- are there any inexpensive or free ICE server
implementations? Is there a weblog covering news of ICE deployment? How can
I dip my toe into ICE without making a substantial investment in time or
hooking up with someone like iSyndicate, or getting a personal tutorial? I
tried to understand the ICE spec when it came out, and even considered doing
a server in Frontier to undercut Vignette's price, but it was dauntingly
complex, so we didn't pursue it. But two years have passed now, perhaps the
situation has changed.

BTW, I'm not assuming that all implementations are hugely expensive, these
are real questions. A sample implementation in a popular scripting
environment, that was free or inexpensive would do a lot to further an
understanding of ICE and what its capabilities are, and help it achieve
independence of Vignette, who is not known as a friend of the individual
publisher.

The sports scores application sounds quite compelling.

Dave






----- Original Message -----
From: "Laird A Popkin" <laird@io.com>
To: "Dave Winer" <dave@userland.com>
Cc: <xml-dist-app@w3.org>; <eric@w3.org>; <bernhard.dorninger@scch.at>;
<ice-ag@egroups.com>
Sent: Saturday, May 20, 2000 4:24 AM
Subject: Re: XML protocol comparison


> It depends on your goals.
>
> Passing around pointers works if all syndicators operate large web sites
> that they want to drive traffic towards. One of ICE's goals is to allow
> small content creators without an online presence (and all of the
> infrastructure that implies) to package their content for syndication by
> service providers, aggregators, etc. Thus, ICE can be used by writers to
> send stories to their publishers (for example) simply by dialing their ISP
> and triggering an ICE "push".
>
> Shipping content rather than pointers also allows receivers to repurpose
> the content, integrating it into their site directly from a structured
> feed, rather than by retrieving web pages and attempting to reverse
> engineer structure.
>
> Simple pointers, such as you propose, also have some synchronization
> problems. That is, they work fine for content that changes relatively
> infrequently. The delay between pushing out pointers and the retrieval of
> the content should not be an issue for book reviews or headline news, but
> doesn't work so well for small pieces of rapidly changing information such
> as sports scores or stock tickers; for such applications, in-line content
> transmission is more efficient and eliminates the synchronization issues.
>
> Additionally, retrieving content from pointers somewhat assumes that the
> use of the content is on the web, and while ICE uses the internet as its
> transport, there's no restriction on the manner of the use of the content.
> ICE over the internet is being used as an alternative to proprietary
> networks, for example, in applications that have nothing to do with web
> sites.
>
> All that being said, there's value in both models (content transmitted
> in-line or by reference), and both communication models are supported by
> ICE. Thus, the content provider can determine which communication model is
> appropriate for the specific application.
>
> For examples of ICE being used for content both in-line and reference, ICE
> is being used both to syndicate the full text of stories (e.g. Reiters)
> and to syndicate headlines that draw traffic to a web site (e.g. CNET).
> And, at the protocol level, ICE packages support encoding content both
> in-line and by reference. The intent is that for small pieces of textual
> data, in-line encoding is more efficient, while for transmission of large,
> binary objects, transmission by reference is preferable.
>
> On Sat, 20 May 2000, Dave Winer wrote:
>
> > Here's an example of why ICE doesn't work as a syndication standard
(with
> > apologies to Microsoft for using this particular story as an example).
> > Scroll to the bottom of the article:
> >
> >
http://dailynews.yahoo.com/h/zd/20000518/tc/standards_bearers_no_need_to_cry
> > _wolf_1.html
> >
> > The writer says: "What's your take? Is Microsoft muddying the standards
> > waters, or acting within its rights? Talk back below and let me know
what
> > you think."
> >
> > Look around and there's no place to comment. That's because the story
was
> > written for ZDNet, where presumably the readers have the opportunity to
> > comment. On Yahoo, there's no place to comment, and even if there were,
the
> > comments would be disjoint from the comments on ZDNet, and perhaps a
dozen
> > other places this story appeared.
> >
> > A different model would for ZDNet to pay Yahoo for delivering a reader
to
> > the one and only place the story appears. That way if there were some
> > excellent comments everyone could see them, and further, if there were
more
> > details to be added to the story, the author could add them.
> >
> > To me, this is a perfect illustration of the web being turned into
email,
> > and failing. The web is the web, pass around pointers, not stories.
>
> Keep in mind that ICE supports both "pointer" and in-line content. You
> haven't "proven" anything about ICE. You have "proven" that you shouldn't
> distribute data that is dependent on site-specific functionality. Instead,
> if the data is by definition site-specific, you should syndicate "teasers"
> that drive traffic to the source site. Or course, ICE supports this case.
>
> Shipping around "teasers" rather than content is great for web sites
> exchanging editorial content (HTML) used in simple ways. And this is a
> case that ICE supports, and which the ICE AG suspects will be a popular
> early case of syndication; while it's of limited utility it is sufficient
> for some applications, and fairly trivial to implement.
>
> Content syndication is not limited to web sites, or HTML. Indeed, many of
> the more interesting applications involve business-to-business data
> exchange, such as National Semiconductor's use of ICE to exchange parts
> data with its business partners.
>
> And, of course, editorial content can be used in more sophisticated ways:
> aggregators typically merge many different feeds into their site, where
> the content is merged into a content management system for a wide range of
> uses. For example, some content may flow directly to a web site, other
> content may be indexed into a resource database for reference use, other
> content may be "sliced and diced" into component elements for use across a
> web site. A typical example would be sports scores, which are transmitted
> in messages that contain a variety of scores for games being played. That
> single incoming message must be parsed into its component scores, which
> are stored in a database that is used by a web site that generates pages
> for current games, team records, and so on, meaning that one incoming
> message may cause dozens of web pages to be updated in relatively complex
> ways.
>
> ICE supports the trivial case that you prefer (push files by reference,
> whenever the sender wishes). It also supports in-line content encoding,
> pull, confirmation of delivery, negotiation of delivery means and
> schedule, state management, auditing, meta-data regarding intellectual
> property, atomic use, copyright, etc., all of which are important in the
> business of content syndication. Just to make it clear, ICE was designed
> by a collection of companies with decades of experience in content
> syndication across a wide range of media and industries. To be a valuable
> protocol for allowing that business to efficiently and reliably operate
> over the internet using a standard protocol, ICE needs to do more than
> simple "ship around pointers."
>
> That being said, I would be interested in spending time with you to walk
> through the "minimal set" of ICE functionality. Our goal was to allow
> implementors who chose to support only the simplest case to implement a
> very small number of messages.
>
> I suspect that if you look closely, ICE can be used to implement the case
> you prefer quite easily; it's just not restricted to that case.
>
> > Dave
>
>

Received on Saturday, 20 May 2000 08:45:34 UTC