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
