Curiosity is bliss

Hosting ASP.NET in IE

The CodeProject article, "A Simple protocol to view aspx pages without IIS implemented in C#", is intriguing.
It uses a custom protocol handler (aspx:) that instanciates the ASP.NET runtime, sends it the request and reads the response back to IE, allowing to test aspx files without a web server.

The web.config and global.asax are searched back to the root in the file path.

There are some limitations like problems with cookies and mime-type headers. Also you probably need to be careful not to jump out of aspx: back to the http: protocol.
I'm not sure whether the HttpRuntime is instanciated at every request or if a trick is used to make it stay alive in the background (required to maintain session state).

Another article on instanciating the HttpRuntime for use on the desktop.

Tablet PC ideas

Three ideas:
- using the Tablet as a terminal over a USB link,
- a BIOS level note taking application,
- hibernate to Flash RAM for faster wake-up.

USB Terminal:
Allow to use a Tablet (or laptops) as a screen or terminal (screen + input, ie. keyboard & mouse) for headless machines. Also, a Tablet could be used as an input peripheral for graphic designers.

The headless machine should have a special USB driver installed for "terminal" devices. You would then run a client software on the Tablet so that the USB port appears as one of these terminal devices.
Whenever you plug the USB cable in, a data link is established between the driver and the client, and the Tablet display a login prompt, like the RDP client does.

I originally thought about suggesting a VGA input on Tablets, but that means separate cables are needed for the keyboard and mouse connection. USB won't support video streaming, but should be enough for RDP, VNC or X.

Update:
Just found a related USB Monitor idea over at Halfbakery.
Someone pointed me to MaxiVista, which is kinda related, but definitely cool. It is a way to make a machine multi-monitor by using the network and another machine as the secondary display. Be sure to check out the awsome demo video. Gizmodo just posted a review of MaxiVista.

BIOS-level Journal:
Allow Tablet PC owners to take quick notes without booting windows.

This would be similar to the BIOSes that contain email client, browser or DVD player software. There would be no ink recognition at the BIOS level, but when starting the Tablet PC OS, these quick notes could be accessed and converted to Journal or OneNote format.

Hibernate to Flash RAM:
There are two sleep modes: Standby and Hibernate.
Standby minimizes the electric load while maintaining the computer turned on: the hard-drive spins down, the CPU goes in a power saving mode, but the "live" data stays in the RAM. Hibernate stores all the data from the RAM onto the hard-drive and the computer is then turned off completely.

This means the Standby still uses some battery, but is quicker to wake-up than the Hibernate, since it doesn't need to wait for the hard-drive to spin up during start-up.

The Hibernate mode could probably be improved by adding a Flash RAM component to the computer, matching the size of the RAM. The question is whether a 150$ addition (for 500MB of Flash) is worth the speed-up, because the devices (network, sound card,...) still need to be re-initialized.

When starting up, not all the data stored in the Flash RAM would have to be copied over to the RAM. Some could be left on the Flash, but flagged in the memory controller as "copy from Flash on Read" so that it gets lazy-loaded.

Games?
The Dots! powertoy has a nice pen-enabled interface, but the game in itself is pretty lame... :-(
I've tried to come up with some game ideas for Tablet last week and over the week-end, but no killer game yet ;-) Any ideas?

Update: Added the Hibernate to Flash idea.

HTTP 101

...what one should know about HTTP...
After explaining the basics of HTTP to a number of people around me, I decided I should write it up.

Introduction:
HTTP means HyperText Transfer Protocol. A protocol is just a convention for computer dialogs. The same way that you don't start a conversation with somebody by saying "goodbye", or that you don't interrupt somebody speaking, computers need to follow certain "social" rules when communicating.

It assumes that the computers participating in the conversation have a way of sending messages to each other.
This is implemented by other protocols that go into the details of how electronic signals should be sent on the wires. These implement an abstraction, called sockets, that looks pretty similar to a tube that transports letters.
When two computers have set up a socket between them, they can start sending words to one another, it is just a matter of sending words in a way that they both can make sense out of them and don't stay silent when it's their turn to "speak".

Request & Response:
HTTP uses a simple conversation pattern: the client connects to the server with a socket, initiates the dialog by asking the server for something, the server then tries provide the client an answer back.
An analog of a simple HTTP request and response would be the client asking "give me the file A" and the server answering "I have it, here is the content of file A: (...content of file A...)".

But in reality the protocol uses its own simplified language which looks more like "GET /fileA" answered by "200 OK (...content of file A...)". Check the links at the end of this article for the complete reference documents.
We'll now go into more details of what this language looks like.

Click for larger view

Loading a web page:
When a browser loads a web page, it does a GET request for the url requested. The content of the page is usually in a special text format called html, that allows to include links, images and other style effects.
The browser analyses the html in order to display it to the user. But doing so it may find that it needs more content to render the page correctly, like images.

When that happens, the browser initiates one HTTP request for each image.
When all the necessary information is downloaded, it is combined into the page the user sees on his screen.

Click for larger view

Experiment:
Telnet is a program that lets you establish a socket connection to a server and manually type the characters you want to send. The command-line syntax varies a little bit, but the principle stays the same: you want to provide the name of the server and a port number. The standard port number for HTTP is 80.

Try the following:
In a windows command prompt, type "telnet google.com 80" followed by return.
A connection will get opened and you are now free to send characters to the google server.
You can quit the telnet program at anytime, by hit (control) ] then type "quit" followed by return.

Continue typing: "GET / HTTP/1.0", followed by return twice.
Depending on the telnet program, the characters you type might appear in the console, or not (but you can type it blindly).

This is the simplest request you can send.
The extra blank line signifies the end of the request and as soon as you type it, the google server will start replying something like:

Request & Response format:
Both the request and response have three parts: the first line, which is either the request line or the status line, a number of introductory lines, called headers, and a content block, called the body.
The request line says what resource the client is trying to access and the status line provides the status of the processing for the request.

Request format:

In our simple experiment, we didn't have any headers in the request, we just had the GET line followed by a blank line.

The action in this case is a GET which is the most frequent one and is used for getting files. But other actions are available, like POST, used when the browser wants to send the content of a form back to the server. Both are very similar except for the fact that POSTs use the body of the request (to send the form data) whereas GETs don't have a body.

Note that line breaks are represented by a pair of special characters, a carriage return followed by a line feed.

The server can choose than handle requests like GETs by either returning static or dynamic content. For example, when you get a file, the web server just loads the (static) file from the hard drive and sends a copy back to you. But it is also possible that the content be built on the fly (dynamically), like Google's search result.

In most case where the result is generated, more parameters can be passed to the server using a special format called querystring. Instead of just asking for a given path like /fileA, you would ask for /serviceA?param1=value1¶m2=value2.
For example, if you perform a search on Google, you'll notice that the words you typed in will appear in the url of the results, as a parameter called "q".

Response format:

The request format makes it easy to tell when the request is over. In the case of a GET, when a blank line is received, the server can starts sending the response back.
First it sends the status code (200 means the file was found) with a short description text, followed by some headers (to specify things like the size of the file or the last time it was updated) and terminated by an empty line. Then it sends the content of the file.

The client knows he has received the whole file either by checking the length of what he has received against what was announced, or if the length wasn't specified, by waiting for the server to close the connection.

More status codes are available, like 404 (File not found), 302 (Resource has moved) or 500 (Internal server error).

POST action:
When you fill a form in a web page and click the submit button, the browser generally do a POST request back to the server. Let's consider a registration form that prompts you for a user name and password, then the request might look like:

When the server receives a POST for the form submission url, he'll look at the body of the request (username=dumky&password=secret) which uses a standard format, and extract the username (dumky) and the password (secret).
Then he'll check whether the username is already taken. If so, an error page is returned. Otherwise, the new username and password are stored in the server's records and the registration succeeded.

Headers:
Headers allow for extra data to be passed with the request and the response. Each line looks like Header-Name: header;data.

One of the most frequent headers that can be found in an HTTP response is the Content-Type. It tells what kind of content is being returned. Each media type has a special name (mime-type): a text file would use text/plain, an html file text/html and a jpeg image image/jpeg.

Another one is the Content-Length. It tells the client the size of the content being returned.

For 302 and other 3xx redirection status codes, the response should also contain a Location field that points the browser to the new location for the resource.

The request can also contain headers. For example, the Accept header field allows the client to restrict what media types the server should send back.

The Referer field indicates the url where this link was found. For example, if you are on a google page and click on a search result at yahoo.com, your browser will tell the yahoo.com server that it came via that google page.

Some header fields are a bit more rich, like Set-Cookie and Cookie (described in HTTP State Management Mechanism), as they work as a team.
Whenever a response contains a Set-Cookie directive, with a certain cookie value, the browser is supposed to send that value back to the server in subsequent requests, using the Cookie field.
This is a way for the server to avoid remembering some things, but asking the browser to remember them instead.

Other headers are available to make HTTP more efficient, like cache directives. Also there is a way to chain multiple requests and responses re-using the same connection (Keep-Alive field in HTTP/1.1), because opening new connections takes time.

Conclusion:
HTTP is rather simple once you understand the fundamentals. It's just a question of learning new actions and headers.
It is a rich and extensible standard, defined across many reference documents, so it feels like you can always find some new hidden features.
But it is most definitely a worthwhile topic to learn, even if you don't work in web development, as HTTP really is universal.

Let me know if some parts of this article need some further clarifications.

Links:
The specifications of HTTP version 1.0 and HTTP version 1.1.

iFolder open-sourced!

Miguel announced that Novell just released the source for iFolder and its underlying metadata store (Simias). That shows the power of mono to enable cross platform scenarios based on .Net.

See the Novell Forge project page for iFolder. I look forward to reading their source :-)

One thing that seems a tad limited is the P2P aspect, since it apparently requires that you be on the same network. C# implementation of JXTA anyone?

Update: Slashdot's report.

Structures and algorithms references

Quick links for a dictionary of algorithms and data structures and a book on exact string matching algorithms. (via HotLinks)
More bedtime reading ;-)

Update: The memory management reference, via Simon's linklog.

Running Java on top of .Net

Miguel demonstrates how to run a simple Java application using the Gtk# libraries and the .Net runtime. Complete apps like Eclipse can be run too, impressive!
You can either pre-compile Java bytecode to .Net IL, or have this done on the fly by a JITter.
You need to export (netexp.exe) the .Net assemblies you want to use from the Java code. I curious how IKVM exports some .Net types like events and delegates, but haven't looked much at it yet. Update: The IKVM weblog just posted an answer to these.
Also, I wonder if debugging works well through the whole stack.

This brings more water to the debate on the future of the open source desktop platform. Java bytecode, .Net IL, wrappers,...?

Using friends as filters

How often do friends send links to you via IM or email?
How often do think about a friend when you stumble on an interesting web page and want to share it with him?

Friends can act as great filters, by picking the stuff they know is relevant to you. They already tend to do so very naturally.
Why not use distributed brain power to go beyond the number of RSS feeds you can follow at once, by making these scenarios simple and efficient?

Here is a suggestion for integrating RSS feeds with social networks: why not allow my buddies (in a certain social network like say MSN Messenger or Orkut) to send me links that would queue up in a special feed that I would receive?
The implementation wouldn't be very difficult (either use a bookmarklet, custom browser context menu or simple plugin). It would open a popup to quickly select some buddies, input a little comment (prefilled with the link name or page title) and send it to their feed.
A technical issue is that you need to be signed in, so that the list of your friends may be displayed in the popup.

The same could be done with email instead of RSS, just with a different interruption model.
Some processing may be done on the feed to group items on related topics.
This system would let me "send myself" links that I want to keep in my stack for later checking.

There is another fundamental problem which is interoperability between friend networks. The same way that the MSN and AOL messenger currently aren't connected, MSN buddies and Orkut friends are separate social networks.

FOAF + de.licio.us discusses a similar idea, except that the relevant is implicit or inferred instead of explicit. But not all links followed by my friends are more relevant to me, so I still like the idea of streamlining manual recommendations better.

Zephoria on RSS feeds for friend recommendations.

A tutorial on using Messenger's buddy list and other APIs.

Essential food: "nutella"

Many people don't seem to know what Nutella is. It is simply put the most delicious and addictive hazelnut chocolate spread in the world. It makes for great breakfast, snacks, deserts, spread on bread, croissants, crepes or anything else you fancy, with a drink of milk or orange juice.

Next time you go grocery shopping, look for the magic little jar, usually in the breakfast/jam section. Your kids (if you have any) and friends will love you for it ;-)
But be aware that once you tasted this sweet goodness, it's hard to let it go.

All you ever wanted to know about Nutella (nutritional info, history, recipes) on the official website.

Some bloglines ideas

Here are some suggestions to make bloglines even better, at least to me ;-)

• Allow the left frame be moved to the right side instead and allow hiding it. The list of blogs takes too much room when reading on a vertically oriented screen (Tablet PC).
• Having an option to display only the titles, show the excerpt with a click and CSS. Big excerpts and large blogrolls make up for a lot of scrolling. This could be done by allowing each user to customize the site with his own CSS and/or javascript (bloglines would only have to store the url for the css and js files). I'm sure hackers would come up with tons of cool tweaks if that kind of customization was supported.
• Allow rating posts (help identify low signal/noise blogs in my list) and monitor my clicks on links (that's an implicit rating).
• Offer a solution for tracking comments that I posted on other people's blogs, as I mentioned recently.

Update: Bloglines now lets you choose between a couple of display options for entries (titles, summaries, ...) and allows you to ignore updated items.

Update (2005/09/21): Start.com implemented the concept of loading distributed components (javascript + CSS). It's called gadgets. Pretty powerful stuff.

I/O gadgets

Here are some input/output gadgets that look pretty cool:

• A pen-shaped document scanner: DocuPen. I wonder if software could put the page back together, removing the distortions.


• A pen input device for cellphones from Nokia. I wonder why more smartphones don't allow sending ink messages yet, since it seems more convenient than digipad typing.


• One more head mounted display. Although I really look forward to having one of these and nearly bought a SV-6 from MicroOptical, the social pressure of looking seriously weird is still too strong ;-)


• Production-ready e-paper from Philips (see the video). It feels like e-paper has been "nearly done" for longer than Duke Nukem Forever now and I'm still waiting for an actual consumer device from E-Ink.


• Wearable keyboards like SenseBoard or LightGlove (via I4U). I also own a HalfKeyboard and just ordered a Virtual Keyboard.

Update: There is also the matchbox sized projector ;-)
I also forgot digital pens like Logitech's io pen, but it's still too bulky and could use some support for converting to Tablet PC's ink.
Another wearable display: Second Sight.

Update: I just saw the sixth episode of "24" (third season) and noticed that Chase wears a MicroOptical wearable display. Cool ;-)

Links:
A photo of the virtual keyboard in action.
An illuminated USB cable.

Comment authentication

How do you authenticate when posting comments?
How do you follow up on comments you posted?

Simon's comment authentication via url ownership
Simon Willison designed and prototyped a nice solution to authenticate yourself by a url (say your blog's address).

The bookmarklet and your home server share a secret (a key). This secret is used when posting a comment, which will allow the comment server to verify that the home url you used knows the same secret.
Something unique to the transaction is signed using that secret key by the bookmarklet. It can be the comment itself, the url for comment form or some random challenge issued by the comment server. The comment server will then find the signature verification url responsible for your home address and submit it the same challenge. If a matching signature is returned, the owner of this home page did in fact post the comment.

The verification server is linked by your home page, using a link tag like <link rel="sigserver" href="http://signature-verification-url" />.

Flow:
I'm going to make a little diagram for this (on my Tablet, tonight), but for now, here are the steps in Simon's comment authentication (to prove you own a url). It involves the user/browser, the comment server (where the comment is posted), the user's homepage and the user's signature server (sigserver).

1. Get comment form
2. Get back comment form and challenge (may be implicit)
3. Fill comment and "homepage" url
4. Run bookmarklet (includes a solution/signature in the comment form, using the secret key against the challenge)
5. Post comment + challenge (may be implicit) + solution/signature
6. Comment server queries homepage to get sigserver url
7. Comment server submits challenge to sigserver
8. Comment server gets signature back and compares with user submitted signature

Click for larger view.

Notes:
The challenge is implicit if it is the url for the comment form, for example.

I think there is a flaw in this protocol though, as I could use Simon's sigserver to sign something for me (using the signature verification interface) and post a comment with the provided signature. The most straight forward fix is to have the sigserver output a hash of the signature instead of the signature itself.

A limitation of this system is that it requires a bookmarklet that contains secret information. First bookmarklets may be sensitive to browser compatibility issues, then it may be inconvenient to use a bookmarklet on a public computer.

Alternative url ownership proof solution
The Padawan proposed verifying your email address instead of your url. Although I like verifying your url better (since you probably don't want to display your email address in the comment and url verification can be synchronous), it got me thinking.

Validating an email address means you have access to this email storage. Validating your url could mean your able to post something to that url, or store something there. For example, the comment server could challenge you to post the number 1234AFFDEC to your sigserver, so that it can then check you actually managed to do it.
Here is my solution, using this principle and using cookies and redirects rather than the bookmarklet (which introduces one extra hit on the comment server and another one on the sigserver).

Flow:

1. Get form from comment server
2. Fill the comment form, specify your homepage url and whether you want to sign
3. Post the comment
4. Stop here if you didn't select the "sign this comment" checkbox
5. The comment server gets the sigserver for your homepage and saves the comment
6. The comment redirects you to your sigserver url with some standard querystring parameters: SubmitChallenge (some random number) and ReturnURL
7. Your sigserver verifies your identity (using cookies and showing a prompt if necessary), saves the challenge and redirects back to the ReturnURL (which is hosted by the comment server)
8. Get redirected to the comment server with the querystring parameters included in the ReturnURL (which we'll specify in the next paragraph)
9. The comment server verifies the querystring (since it generated it, it may be signed with the comment server's secret key)
10. Verify whether you passed the challenge, by doing a server to server HTTP request to the sigserver with the querystring parameter VerifyChallenge
11. The sigserver can remove the challenge from its storage and answers with HTTP 200 SigVerified (or some other code if the verification failed)
12. The comment server can now mark the comment as "homepage verified" and can decide what to display to you

Click for larger view.

Notes:
The ReturnURL is generated by the comment server and needs to contain enough context information, like the comment id, the challenge, the sigserver's url and some signature (so the comment server knows this url hasn't been tampered with).

If the first request to the sigserver contains the CommentURL in addition to the SubmitChallenge and ReturnURL, then the sigserver can track all my comments. Also the sigserver now shares a secret with the comment server, namely the challenge token, which can be used for further trusted notifications.

If you are not using your own computer, you probably don't want to leave the authenticating cookie used by your sigserver. This can be solved by using a "use session cookies" checkbox on the authentication form of your sigserver.

If for some reason the flow fails and the comment doesn't get verified, the comment server could trigger the flow again when you click on the "url not yet verified" link.

Afterthoughts:
I've been thinking about this since yesterday and I decided I like Simon's solution better. I doesn't add many server hits (only one on the homepage and one on the sigserver) and requires minimal change in the comment server code. Also, I use my own computers most of the time and don't browse with lynx very often ;-)

As I mentioned, to make Simon's protocol more secure, the sigserver shouldn't return signatures but instead hashed signatures. This proves the comment server that the sigserver knows it, without revealing it.
Similarly, I think the comment server should prove the sigserver that it also knows the signature, during the signature verification exchange. This can be done by passing a salted hash of the signature along with the salt used. At the end of the verification request both the comment server and the sigserver share a secret: the signature. This can be used for further interactions, like notifications of replies.

Links:
I need to look at Dave Winer's "You Know Me" button and Ben Hammersley's variant, but I didn't have time today.

Also I have seen some mentions of ShareID which I didn't look at in details too much yet (it seems partly centralized).

Commentblogger bookmarklet, a simple but a bit limited (manual) way of logging the comments you post.

There is a draft for an entity header for linked resources. Instead of using <link> tags, the links could be returned in the HTTP headers, as in Link: <compact.css>; rel="stylesheet"; title="compact".

A PGP-based auth-by-URL solution, which is similar to Simon's solution, except with asymmetric cryptography (PKI). The homepage/auth server doesn't need to have a signature verification service, it just needs to publish a public key.
The downside is that more complex computation (with libraries that aren't necessarly provided by most hosting services) is done by the comment server, and the client needs to run some PGP software, instead of a simple bookmarklet with an MD5 javascript library.

Update:
A comment tracking system proposal called talkr.net, based on the flickr authentication service.
The description of SimpleID and it's implementation. SimpleID is not really an authentication solution, mostly a de-centralized form pre-filling system.

Are libraries the new languages?

I was re-reading a chapter in "Gödel, Escher, Bach" last night, where Hofstadter introduces notions of programming (machine language, assembly, higher level languages). It made me wonder: What is the next step in the evolutionary tree of programming languages? What will make the coder's life easier?

Assembly definitely simplifies coding compared to machine language. Similarly, modern languages like C, C++, Lisp, Caml, Perl, Prolog, Java and C# all aimed at making hard problems even easier to solve, using various typing, objects, memory management, interpretation/compilation/imperative/declarative/functional... approaches.
(Note that high-level languages don't make it easier to write the "same" program, they are only "equivalent", with differences in the low-level details because of the abstraction. As Hoftstadter puts it, "... in using chunked high-level models, we sacrifice the determinism for simplicity".)

All the new languages I have heard of seemed to fall in the existing classifications: it integrates such feature from language A, such other from language B and so on. Of course, Java and C# Generics aren't exactly C++ templates, but the concept isn't that different either.
At the same time, object oriented languages can be enriched a lot just by creating new libraries. For example, declarative UI markup like XAML is a nice domain specific language, but it can be added to .Net as a set of assemblies, using code generation. In the same way, rich/simplified peer to peer connectivity is available in Java via a framework like JXTA. Does that mean we don't need new language features? Will frameworks overcome Joel Spolsky's law of leaky abstractions?

In "The Hundred-Year Language", Paul Graham describes an interesting evolution path: data structures could become optimizations from the compiler.
It may also be that some OS concepts need to evolve as well for the languages to start mutating again. For example, capability secure languages take their full power on an OS that supports the same model.

Are new languages just a combination of previous ones? Are we just adding syntactic sugar? Are libraries and tools (annotation, verification, unit testing, instrumentation, profiling, ...) the main areas of improvement these days?

Some current problems with languages I can think of:
- string building and parsing: lots of SQL queries and HTTP urls are still built by hand, which is subject to errors when special characters occur (maybe the code editor could help by smartly displaying escaped strings),
- data access: DB access still requires a lot of domain specific knowledge to be done properly,
- security: can languages help limit complexity and thus the security problems?

Update (2006/03/16): Re-watched Todd Proebsting's great talk on disrupting programming languages technologies (video + slides).
In short, for a disruptive language to be successful, it needs to be worst than existing languages (performance is a good first casualty) but better at solving the concrete problems of a minority of the audience. The areas were he sees such opportunities are: support for concurrency and distributed programming, recording/debugging capabilities, support for checkpoint/undo/redo, database integration, integrated XML support, rich parsing and constraint solving.
Incidentally, the first question from the audience at the end is when should a feature be integrated into the language rather than added as a library?

Update (2008/04/12): I have noticed a few recent libraries which make it appear as if they stretch the language: Parallel FX, PLINQ and DryadLINQ. On the other hand, the language improvements in C# greatly contributed to making such extensions seamless.
From extension methods, anonymous types, lambda expressions and type inference, to dynamic code generation, C# is really maturing and enabling new problems to be experimented with and solved in "application space". This is inviting a new kind of thinking for library writers.

Decompression bombs vs. RIAA

I read recently about how the RIAA could use audio fingerprinting to identify copyrighted material on P2P file sharing networks.
I also heard about decompression bombs and thought about using that concept to protect P2P networks.

Is it possible to make the decompressing of a file expensive, using a standard compression algorithm?

This could be done using cryptography, either distributing the key along with the encrypted file or even having it bundled in a self-decrypting executable. But using a standard decompression algorithm like gzip or bzip2 would make distribution easier (only the compression would require a new tool).

This would make it costly for automated content analysis on a large scale, while not being a problem for individual users, the same way that hashcash and other proofs of work make it uneconomical for spammers but not casual users.

Update:
A related article was just posted at the NYTimes: A Software Program Aimed at Taming File-Sharing.

RSS-free day of the week

I've had lots of trouble balancing my time online lately, between blog reading, publishing and code writing. Although I don't use the bloglines update notifier, I leave bloglines opened in a tab and check it regularly. Unlike Steve Gillmor, who also is a confessed RSS addict, I can't bear leaving items un-read for as long as a day.

But as my subscriptions continue to grow, I spend less time hacking and publishing. Its feels like being an information junky, in need of a quick fix. And like channel hopping on TV or junk food, it leaves an after-taste of dissatisfaction.
The quick context switching between all these little posts have a negative effect on my attention lifespan and I have to queue denser and longer essays for later reading.

Maybe grouping posts by topic using some smart categorizer based on content and link structure would help prioritize posts. This would help to limit the fragmentation, replication and dilution of information, by grouping the "title+comment+link" posts that are alike together.
Another solution is to prioritize feeds themselves using some tivo-like thumbs-up button in aggregators. I've been wishing for this a long time, as it would help identify the feeds that don't have high enough signal/noise ratios for me, push them to the bottom of my subscription list and eventually trim them off.

But I'm thinking of a more radical solution, like having a personal RSS-free day in the week. I haven't tried it yet, and it would sure help if bloglines had a feature to enforce it ("sorry, no feeds for you today, come back tomorrow"), but I think it would make feeds more manageable for me, by artificially inserting a break and let all these ideas sort themselves and decant.

Links:
RSS: A Big Success In Danger of Failure.
Falling out of love with RSS.

(Cat overdose).