This is an extension of the idea for the delicious replacement. The idea is to treat accesses to a website as messages dropped off - dead letter box style.
Dead letter boxes allow communication to happen without meeting using a pre-agreed signal or format. The idea is to use a web server's log file as a dead letter box for various types of messages. Like so:
404 GET /dlb/tweet/my_tweet_as_an_underscored_resource_name
404 GET /dlb/todo?task=do%20something&priority=high&context=@home
404 GET /dlb/post-blog-entry?title=A%20Blog%20Title&body=A%20uuencoded_string_as_long_as_log_will_take_goes_here
Again, the way it would work is that a job wakes up regularly, greps the web server logs for these error messages, and does what's actually expected from each of these.
Subversion of http's actual intentions? Maybe. But it sure produces a very decoupled way of working - no high capacity web server with custom code to handle all these operations need exist, and new operations can be added in a very decoupled way.
The best advantage of all? As long as you're able to hit a web server - you can tweet, log a todo, post to your blog, etc, and much more. No more need to be connected to each of these different sources.
Next: do the same with email, so that the same functions are available when you send an email. Although you could implement that as an actual email processsor.
Not entirely addressed yet: security. Maybe making it https would suffice?
Dead letter boxes allow communication to happen without meeting using a pre-agreed signal or format. The idea is to use a web server's log file as a dead letter box for various types of messages. Like so:
404 GET /dlb/tweet/my_tweet_as_an_underscored_resource_name
404 GET /dlb/todo?task=do%20something&priority=high&context=@home
404 GET /dlb/post-blog-entry?title=A%20Blog%20Title&body=A%20uuencoded_string_as_long_as_log_will_take_goes_here
Again, the way it would work is that a job wakes up regularly, greps the web server logs for these error messages, and does what's actually expected from each of these.
Subversion of http's actual intentions? Maybe. But it sure produces a very decoupled way of working - no high capacity web server with custom code to handle all these operations need exist, and new operations can be added in a very decoupled way.
The best advantage of all? As long as you're able to hit a web server - you can tweet, log a todo, post to your blog, etc, and much more. No more need to be connected to each of these different sources.
Next: do the same with email, so that the same functions are available when you send an email. Although you could implement that as an actual email processsor.
Not entirely addressed yet: security. Maybe making it https would suffice?
No comments:
Post a Comment