Ken Coar:
Suppose I want to go back and edit out a passage that includes
a link that got tracked to the referred log? Perhaps I now find the
passage embarrassing, or perhaps it is no longer applicable, or
maybe it never was -- regardless, I want to elide it.
Note: the quotation above was valid at the time I swiped
it. The link above was asserted to be a permalink. For all I know,
it may now be 404 or contain gay porn. Follow the link at your own
risk.
yes, the gossamer strands of the web are fragile.. but that doesn't mean we should engineer the fragility into them when we have the option of providing reinforceability and strength.
it's probably much too late in the week for me to be making much sense. maybe i should prototype something into my own trackback implementation so that trackers can revoke their link. less theoretical, more demonstrable.
I'd like to a see a script that can run on TrackBack data, eg the data and XML files produced by the standalone TrackBack client from movabletype.org, and remove
a) any dead links, and b) any URLs you specify, eg spam and mistakes.
Should be easy for the XML data, I'm not so sure about the format of the data files.
Posted by anonymous
at
Ken and anonymous:
My feeling is that this is an area which I personally wouldn't bother to overengineer. Blog entries date quickly (i.e., are pushed down on the ever growing stack), and are full of links of various kinds. Trying to make sure that one kind of link is marginally better maintained if a new API is widely adopted is not likely to make a significant difference overall.
Pursuant to my remarks about making trackbacks revocable, I have added some functionality to my specific implementation. It should fit seamlessly on top of the existing specification. First, in order to be able to revoke a trackback, you need to be able to identify it; since the identifier will ......
[more]
Trackback from Ken's Blog from the Burrow
at
I strongly disagree with the points made in this article. The fact that http is stateless, that there's no "cascade update"-type mechanism, have been essential in making http so widespread. There would be clear scalability problems and complexity burdens imposed on people who develop web applications if these things were requirements.
Discussions that take place in a vacuum about how nice it would be to have this feature or that, without reference to opportunity cost, are pretty worthless. The question to answer first is, what properties of the second most successful protocol in history (after tcp/ip) were the reasons for its success in the first place? I think at least part of the answer is scalability (stateless connections) and a minimization of dependencies on other systems in a WAN (as an aside, the WAN problem is IMO the reason it will be a LONG time until business will depend on critical applications that run outside of their firewalls). That this design is a cause of broken links and other trivial problems pales in comparison to the very demonstrable benefits.
Also I'd like to point out that one thing we don't need more of is people who read the first few paragraphs of something and then respond with wild posts based on too little information.
Pursuant to my remarks about making trackbacks revocable, I have added some functionality to my specific implementation. It should fit seamlessly on top of the existing specification. First, in order to be able to revoke a trackback, you need to be able to identify it; since the identifier will ......
[more]
Trackback from Ken's Blog from the Burrow
at
Web links never die
A couple of years ago, a Japanese music video named “Yatta” spread across the web like a wild fire. Six young Japanese men dressed in only fig leaves, singing and dancing in front of hundreds of Japanese teenagers, seemed too......
[more]