Subject: Open Comments.....

From: "Kevin A. Burton" <[email-masked]>
Date: Fri, 04 Feb 2005 16:23:00 -0800

Any feedback on this guys?  Curious to see what type of interest there 
is here...

http://wiki.apache.org/jakarta-commons/FeedParser_2fOpenComments 
<http://wiki.apache.org/jakarta-commons/FeedParser_2fOpenComments#preview>

-- 

Use Rojo (RSS/Atom aggregator).  Visit http://rojo.com. Ask me for an 
invite!  Also see irc.freenode.net #rojo if you want to chat.

Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html

If you're interested in RSS, Weblogs, Social Networking, etc... then you 
should work for Rojo!  If you recommend someone and we hire them you'll 
get a free iPod!
    
Kevin A. Burton, Location - San Francisco, CA
       AIM/YIM - sfburtonator,  Web - http://peerfear.org/
GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412

---

From: "Roger B." <[email-masked]>
Date: Sat, 5 Feb 2005 01:41:24 -0600

>  Any feedback on this guys?  Curious to see what type of interest there is
> here...

Kevin: Why would anyone want to fiddle around with HTML classes to
indicate comments when they can just publish/consume comment feeds? Or
did I misinterpret the purpose of the effort?

--
Roger Benningfield
JournURL

---

From: Danny Ayers <[email-masked]>
Date: Sat, 5 Feb 2005 11:29:54 +0100

> did I misinterpret the purpose of the effort?

I had the same reaction, apologies if I'm misinterpreting too. The
motto that spontaneously emerged on this list was "It's the Entries,
stupid!" - comments and trackbacks are just entries too, only with
different metadata. Is there something else here?

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: "Bob Wyman" <[email-masked]>
Date: Sat, 5 Feb 2005 14:09:19 -0500

Danny Ayers wrote:
> The motto that spontaneously emerged on this list was 
> "It's the Entries, stupid!" - comments and trackbacks are just 
> entries too, only with different metadata. Is there something else here?
	I strongly agree that "comments and trackbacks are just entries
too..." Given this, I'm puzzled by the various proposals that we need to
somehow incorporate recursive feeds or other structural innovations in order
to address the "comment problem." To me, a comment is just another entry
that happens to have a typed link to the entry which is its subject.
	It is important, I think, to be careful not to permit too much of
our expectations concerning the display of different types of entries into
the feed format itself. While some user interfaces may display comments in a
fashion structurally different then free-standing entries, it is neither
necessary nor wise to allow these structural differences to enter into the
feed itself. Doing so will tend to limit the flexibility of the system and
opportunities to innovate in the future.
	For example, if we establish the relationship between entries and
comments by doing something like providing for an embedded "comments feed"
within a feed document, we may make it difficult to allow cross-feed
comments. i.e. Allowing me to create a comment in my feed that refers to an
entry or comment in someone else's feed. I think this would be very
unfortunate since it is becoming quite apparent that the current mechanisms
for commenting are not going to be sustainable long term.
	The problem with commenting as it is practiced today is that it
relies on granting others the right to write into one's blog. Because
comments and entries are collocated, in order to create a comment, one must
gain write access within the same data administration domain as the entry.
This increases the complexity of comment systems greatly -- or results the
common approach of granting global write access to comment feeds and relying
on post-write moderation of comments. (i.e I get email notifications
whenever someone comments on my blog and I then have to inspect the comment
to determine if it should be deleted.) The tremendous amount of comment spam
that we have is the result of this silliness -- open write access being
granted to our comment feeds. Spamming is much less common and much less
likely when spammers are forced to maintain their "spam" within their own
domains rather then exploiting, like parasites, the domains of others...
	In the future, I think, we'll see comments being written on the
writer's blog which link to the entries or comments upon which they comment.
Thus, rather than a comment being identified as such by being an actual
insertion into the stream of updates to a feed, we'll see comments being
identified by their metadata. Thus, more and more commenting will move to a
track-back model (either explicit via mechanisms like trackback or implicit
via link tracking tools like PubSub).
	To summarize: "It's about the Entries, Stupid!" Comments are just
entries that refer to other entries as their subjects. Let's not allow the
currently anecdotal aspects of commenting implementations to overly
influence the mechanisms that we define for supporting commenting.

		bob wyman

---

From: "Roger B." <[email-masked]>
Date: Sun, 6 Feb 2005 04:13:43 -0600

> relies on granting others the right to write into one's blog. 
> ...
> Thus, more and more commenting will move to a

Bob: Bah, bug, and hum. Comments are just micro-message boards, and
message boards have been getting along just fine for many, many years
without the help of PubSub or any other third party.

More importantly, a reply that exists within the context of the source
and a reply that exists in another space entirely are very different
things... they're written differently, perceived differently, and
often aim for different goals. That's not a problem to be solved.

With that said, I don't think Atom needs to bake in anything fancy for
comments. Personally, I'd be quite content if Joe tapped out a
wfw:commentAtom and called it a day.

--
Roger Benningfield
JournURL

---

From: "Bob Wyman" <[email-masked]>
Date: Sun, 6 Feb 2005 14:47:29 -0500

Roger Benningfield wrote:
> Bob: Bah, bug, and hum. Comments are just micro-message boards,
	Wrong... Comments are just entries that are normally presented to
users in what appear to be micro-message boards.
	As is usually the case in software design, it is very important to
ensure that you don't allow attributes of the presentation to overly
influence the way data is stored or represented. The goal should be to
ensure that the desired presentations are possible, however, if you allow
any one presentation to overly influence the storage and processing design,
you will almost inevitably prevent the use of alternative presentations.
That would not be a good thing.
	Encapsulating comments in "mini-feeds" or nested feeds certainly
allows one to present comments as though they were micro-message boards.
However, doing that prevents or makes it difficult to implement distributed
commenting without adding new facilities and mechanisms. On the other hand,
if you design for distributed comments and encode the relationship between
entries via metadata, you can still present a micro-message board with
little difficulty. Whether or not you support distributed commenting then
becomes a question of implementation choice, not something which requires
new specification.
	Basically, what I'm saying here is that indicating the type and
relationship between entries and comments via metadata is vastly more
general and useful then doing the same by using file structure to indicate
the same. Given that there is little cost to using the metadata approach, I
argue for it.

> message boards have been getting along just fine for many, many
> years without the help of PubSub or any other third party.
	You are, of course, quite correct. However, now that we have PubSub,
Google, and a variety of other tools that can be used to find referential
connections between objects on the web, it seems like it would make sense to
attempt to exploit these new tools to provide better or different services
to our users. I don't argue that message board require the services we
provide, only that it would be a shame to implement a system that made it
hard for some innovative developer to use these services.

> More importantly, a reply that exists within the context of the
> source and a reply that exists in another space entirely are very
> different things... they're written differently, perceived
> differently, and often aim for different goals.
	I couldn't agree with you more. The big difference is, of course,
that a reply that exists within the administrative context of the source has
some measure of "authorization" attached to it. i.e. the maintainer of the
context has authorized, permitted or tolerated the reply to exist in that
context. However, this does not argue against implementing support for
replies that do not exist within the same administrative context as the
source. If we have a method that can support both types of reply better than
another method that is best for only one type, then I think we should adopt
the more general method. It then becomes a property of applications to
determine how to distinguish between the two types. (Perhaps different
colors, icons, etc.?)
	We've seen the same distinction as is seen here in the difference
between normal trackback (which allows any random person to insert a back
link into a blog) and the sort of "automated trackback" that you get if you
link to the Technorati Cosmos or a PubSub link feed in your blog. Just as
you suggest, the embedded trackbacks and the "computed trackbacks" are
thought of differently, perceived differently, etc. Nonetheless, both types
have proven to be useful. If we can support both with a single method -- why
not do it?

		bob wyman