Yesterday's most-read sites
This page ranks the most-read UserLand-hosted Manila sites. Hits are tracked between midnight and midnight Pacific time.
Also, we have a new facility that ranks sites over time, not just for yesterday. But we want to let it run for a few days before rolling it out. The results, not surprisingly, are pretty much the same as yesterday's most-read sites.
Note: This page counts page-reads only, not graphics hits. It doesn't count page reads for statically rendered sites, that's why Qube Quorner, Inessential and Scripting News, as examples, don't show up in the rankings.
It's still not perfect, but it's much better than what we had previously.
Boston Globe: "Major record companies ought to go beyond legal stratagems to define a marketing program that fully utilizes the MP3 format. The songs of Metallica and other famous artists ought to be available for a small fee, and the work of those popular acts ought to be featured on the same site as those of emerging artists, as MP3.com had planned."
Adam Curry has a weblog. He was one of the original MTV vjs. He could help, again, move music to a new medium.
BTW, my interest in the intentions of the music industry are not that idle. Looking at the most-read-sites list, see which is the most popular site, and imagine why. People like music.
Ken MacLeod: Web RPCs Considered Harmful.
Murphy speaks in strange ways, and no doubt Ken with 20 years of experience in systems has heard the voice of Murphy in ways that I haven't. I respect Ken, a lot, so when he speaks, I listen. I've known him on the Web for a few years, but I've not met him. He will be in Amsterdam, I'm looking forward to shaking his hand, and having some really interesting talks.
OK. UserLand has built quite a few mission-critical applications on XML-RPC. When you use our search engine, or Pike, or Manila Express, or set preferences for UserLand.Com, you are using XML-RPC. We like it. The apps are easy to create, and quite powerful, and offer us a scaling strategy that we depend on in our server architecture.
In Ken's scenario, you could consider these one-off implementations, because at this time there are few apps (that we're aware of elsewhere) that are compatible. However, we do want people to develop compatible applications, for good reasons, I think. (User choice is #1.) And ZopeFish appears to work, so we're on the verge of getting a compatible application of the Manila-RPC interface in Zope, which has been a long-term goal.
A story. Last year we talked with a portal about doing work with them, perhaps merging. We did due diligence on each other. The company had been acquiring Internet services at a regular clip for a couple of years. Go to their sign up page, 20+ links, each of which took you to pages where you entered virtually the same information to join each of the services. No integration. The calendar couldn't connect to the email service or the web hosting service. I recognized this as the same problem in the Mac software business in the 80s. Business often demands that companies merge, but the technology rarely supports it. Could we do better with the Internet?
We need a backplane. In our world, content management, we need preferences that travel seamlessly across servers. Search engine data that goes from the CMS to the SE without crawling. Stories flowing across servers. Choice of editorial and design tools. Could we do this with static XML files as Ken suggests? Sometimes. But I don't think you could do all this without a source sending a message to a destination, and as long as we're sending a message, why not send the data along with it, and as long as we're sending the data, why not have a simplifying layer so you don't have to start over every time?
I want a real doomsday scenario, the more paranoid the better. If there's a deal-stopper in there I want to understand it asap.
Edd on Web App security
Edd Dumbill comments on the Zope security alert posted earlier this week. "There are several partial solutions but nothing that preserves the current level of freedom and convenience for both user and programmer."
Hmmm. We believe we've closed the hole in Manila by programming it to care about the Referer attribute on the HTTP request. Edd says the problem is unsolvable, to me it's not all clear that that's true.
Edd says that the browser guys can help, and that is very true. But mostly these days the browser guys work for Bill Gates, and at least based on past experience, that doesn't bode well for fixes.
Joel Spolsky: "Building a company? You've got one very important decision to make, because it affects everything else you do."
Dale Dougherty: Red Hat Backs Away From WideOpenNews.
Dana Blankenhorn: A Word for adXML.
NY Times: "The episode illustrates the vulnerability of computer systems not only to sophisticated vandals but to relatively crude and even unintended acts of destruction."
NY Times: "Almost as astonishing as the stories surrounding Mr. Li's death was the extraordinary back door through which the news first emerged: An anonymous posting in a chatroom on a popular Chinese website."
Susan Kitchens: "When dancing with abandonment at a wedding, make it a point not to watch the videos afterwards."
Elissa Schappell: My mother's 10 rules to live by.
Believe it or not this Web App is a static page and is smaller than 5K. "Let your creativity become an untamed beast within the constraints of this 15 by 15 square cage."
"You can see the smoke"
On MetaFilter, I posted a note on Array's return (there was an earlier thread about Array's disappearance), noting that Garret was covering the fires in New Mexico.
"Eventually the electronic flames ran out of energy, and in an amazing case of synchronicity, the flames showed up in the forests of New Mexico."
A reporter from the New Mexico Daily Lobo posted links to their work. "I live in Albuquerque and you can see the smoke from the Interstate. It's surreal."
This is the Web I work for. A human network covering the world.
© Copyright 1997-2005 Dave Winer. The picture at the top of the page may change from time to time. Previous graphics are archived.