Blog posts tagged "essay"

A Future for Paper

November 19th, 2003

The essay that got away is a favorite character of mine, and shows up in many of my stories. As you can see from the link above, you were going to be treated to a thoughtful, and philosophical treatise on: the future, the idea of paperlessness, and the works of Kristine Smith. However, prompted by Aaron’s revisiting of the topic, here a few notes, and a book review, scrawled by the fading phosphors on a windy, rainy night.

A few weeks back Matt Haughey asked, why are we still using reciepts? We live in a computerized society, why is information still externalized onto pieces of paper? Aaron expounded on the fragility of digital information: digital media’s cycle of obsolescence, the illusion of always on electricity/net, blogs’ rather dismal prospects as bath time reading. Matt Web however got to crux of what interests me about the issue when he said paper receipts are primary keys to a distributed database. You see Haughey’s model requires a centralized database which is implicitly trusted.

One of the core American myths (and to a large, but lesser extent, all of Western society) is the myth of progress — the constant drum beat of the march to the future, a linear progression that renders the old bad, and the new both better and inevitable.


  • books were to be doomed by the information superhighway
  • a love of paper understandable for aesthetic and nostalgic reasons, but on its way out.
  • blogging is supposed to replace/kill old media because it is so democratic/innovative/natural.

One of the favorite tropes of this march of progress is “paperlessness”: the paperless office, the paperless government (egovernment), and, apparently, paperless shopping. A brave new future of the receipt repudiated by the database.

Interestingly current events are starting to wake us, as a society, up to the value of paper. It seems that a central database, affectionate known in the literature as a “Big Brother” model, is vulnerable to a variety attacks, a broad subclass of which fall under the moniker of “Diebold attacks”. Apparently large, central databases, without proper, verifiable audit trails, have some issues. (Google pdf2html version) All of a sudden some people are asking for paper tickets (also known as “recipets”), a total contradiction to our consensus on what the future looks like!

Which makes it fascinating to read Kristine Smith’s scifi trilogy (Code of Conduct, Rules of Conflict, Law of Survival) featuring aging heroine Jani Killian as a “document examiner”, and 2 distinct cultures (one of them alien) built upon (or at least seen through the lense of) paper, paper trails, paper handling, and verifiability. Part religion, part art, utterly techie (such cool gear!), the paper system, and document examiners (dexxies) stitch together the consensus reality of the intergalactic future. The books project forward from trends of today where digital data and records are easily forgeable, and photography no longer meets the criteria of proof in many courts. Dexxies are the hacker-esque trained specialist that keeps the it all working.

At first I was a bit turned off by Smith’s use of words like “shooter” and “skimmers”, they sound like baby talk. No society is going to refer to its weapon as a shooter, not even as slang, sounds moronic, and it is a classic first scifi novel mistake. I almost put the books down at that point, and wrote her off. I’m glad I didn’t as the paper system is utterly unique in my experience of the genre (or any genre). The only futurist I’ve encountered who did take the Micosoftian (think Faustian) hype that we’d all be moving to a paperless existence to heart. Instead she did some original thinking about the evolution of human interactions with information with interesting results.

As a geek/hacker/trained specialist in charge of today’s communication infrastructure I found the paper system to be Smith’s most interesting creation. However her idomeni, alien creators of the paper system, are also quite good, and reminiscent of Cherryh’s Foreigner books. (in fact Cherryh writes the cover blurb for book 3, as Asaro did for book 2, and Moon for book 1) They suffer a bit from “Atevi syndrome” which says that in order to have a really indepth exploration of an alien’s psyche you have to make them pretty damn human, or it is just too alien to be meaningful. Reality is still much more alien then fiction, but Smith is hardly unique in failing that metric.

Code of Conduct is her first book and a bit rough, but over the next two books she settles down to writing good, strong, character driven fiction (which unfortunately seems to have become code for “scifi written by a women”, but I digress) with hackers as heroes, and some genuine insight into the nature of technology.

Lastly, for all I find Smith’s paper system compelling, I would like reiterate my plea for a decent ebook implementation.

  • Writing up these notes would have been greatly facilitated by a full text search feature built into the book
  • I would have felt distinctly less uncomfortable carrying, and reading these books in public if I’d been carrying a generic ebook reader, as Eos has seen fit to saddle them with truly hideous covers as if they got jobbed out to someone who usually works for Harlequin. (Kristine keeps the faith, it only took Bujold a dozen critically acclaimed novels, winning every major genre award, and switching publishers to get a decent cover.)

.pps, in Laws of Survival the rebellious Haarin give a most damning condemnation of the Liberal “play nice” strategy of social change. Warmed the heart.

Tagged: Uncategorized , , , , ,

A Few Tips for Writing Useful Libraries in PHP

August 5th, 2003

(A month or more ago I started writing a blog entry, which became so long I decided to turn it into an article. However life has gotten away from me, and I don’t know when I’ll get around to doing the clean up to write that article, so here it is.)

Zend has an article Writing Libraries in PHP (you’ll have to trust me on the title, as their CMS seems to be broken). It is a good article as far as it goes, but I think the title over sells the article. Which is a shame, because of all of PHP’s many faults and quirks, perhaps it’s most telling (and most crippling) is a cultural one, PHP programmers write applications, not libraries. I don’t consider myself a PHP guru, being more comfortable in Perl and Java, but I do consider myself a good software developer, and so I’ll try to capture a few of the lesson I learned when developing MagpieRSS, my PHP library for parsing RSS.

First, lets identify the problem.

PHP, its a cultural thang

Python positions itself as distinct from Perl with the slogan “batteries included.” Whether you feel that is accurate is irrelevant, because PHP is the real “batteries included” language. PHP bend so far in this direction, you’ll find functions like pfpro_process for talking to the “Versign Payflow Pro” service in the core language. Besides the patent of absurdity of this, its also created a culture that sees only 2 forms of PHP, core language extensions, and applications.

Why is this a problem?

So whats wrong with that? Code written for a particular application is often very difficult to reuse. Code reuse is one of the holy grails of open source, its how you leverage all the vaunted of benefits of “lots of eyes make bugs shallow”, and patches, and shared development. Code reuse also reduces development time, and bugs in applications that reuse the code. Unless of course to reuse your code I’ve had to dig into it, hacking it to suit my purposes, in which case I’ve probably spent more time, and introduced bugs into code I only half understand. I’ll be tempted to throw it away and start over, splitting time and development energy over multiple solutions rather then improving just one.

So what is the difference between an application and a library?

A little over a year ago, I was wanting to syndicate the events from to a website published with PHP. As we generate RSS feeds for our calendars I thought this would be easy. I went looking for a tool to recomend for the website to use, and I came up short. I found many, many, many PHP applications that took an RSS file, and generated HTML, these were applications for displaying RSS as HTML, but they weren’t libraries, they tried to do it all, and therefore couldn’t integrate with this website which had its own way of wanting to use RSS and PHP. A key characteristic of an application versus a library is how many problem it tries to solve; solve too many problems in a single layer and you lose flexibility.

Tips for writing PHP libraries

A few of these tips are theoretical, some are very concrete. Some I’m not thrilled with but they’re are the best solution I have to date. If you disagree, or have suggestions, please add them.

  1. Do one thing, do it well

    You aren’t building a CMS, you aren’t building an interface, you’re trying to support other people in those tasks.

  2. Don’t echo or print content, return it!

    This is one of the key problems you see in much PHP code. If you echo out the results of some function directly to the web page, when I’m trying to use your code to write the output to a file, or run it in a testing environment I’m going to be frustrated. What if I’m trying to build an internationalized app, and you’re echo’ing out English? Don’t assume you know in what context your code will be run, return objects, or strings. Don’t print.

  3. Return data, strings, or objects, not HTML.

    The corollary to the don’t print rule, and abused nearly as often, if not more so, is don’t return formatted HTML. (unless you are writing an HTML widget, in which case that is all you should be doing) If you return the results of your function as a formatted table, it might be pretty and easy to use, but I can’t pass those results to another function to sort them, or integrate it with my pure CSS layout. It is really common to see code like echo('<font color="red">$error_msg</font>');. Don’t do it.

  4. Allow intelligent error handling

    One of the most common reasons a library will print content directly to the web page is on encountering an error. This makes makes it very difficult for the application using your library to figure out what happened and respond accordingly. Don’t assume your code is the most important part of someone’s application, maybe they don’t care if you failed? Or maybe they care a whole bunch, and want to totally change what they were doing?

  5. Use an error() function

    I’m still struggling to come up with the best way to do error handling as a library in PHP. Once PHP5 arrives and we have real exceptions, much of this will be irrelevant. In the meantime.

    What I do with Magpie is provide an error() method for each part of the application.

    error() takes a message, and an optional error level, appends phperrormsg if trackerrors is on, prepends a string identifying the library that is throwing the error, sets up a package/class variable with the resulting error, and, if debugging is on, triggers an error message.

    Why is this good? Code using your library has easy way to check for error conditions (if ($lib->error) { ... do error handling .. } ), error messages are very complete, and consistently formatted, when someone is developing with your app they can easily find out what went wrong based on their php.ini settings, and lastly if someone does need to hack or override your chosen behaviour, they only have to do it once.

  6. Allow simple configuration

    If you don’t provide a way for people to change the behaviour of your library, then you force them to hack on it. If someone has had to go into your code and hack on it, then they’ll be resistant to upgrading as new versions become available, and any changes they make that you want to roll back into the core will be more difficult to apply.

    Configuration can be parameters passed to a class’s constructor, set/get methods called later, or constants defined at a runtime. (more on this later)

  7. Choose intelligent defaults

    This is true with any application, or library in any environment. It is particular true with PHP where a great number of your users aren’t programmers by profession or choice, but just trying to get something working to support their real work.

  8. Break your library into multiple files

    One way to simplify your code, and encourage encapsulation and reuse is to split your library into logically sub pieces, and move these pieces into their own files.

    Something I didn’t do with Magpie, but wish I had was store all the files in a lib/ directory. Having all your files in a single directory makes it much easier for people to install your code. (When it came time to bundle an external library, a modified version of Snoopy, I had learned, and put it in extlib/ )

    This tip is really an excuse for the next tip.

  9. Don’t assume everyone’s PHP looks like yours.

    PHP has a lot of configuration options, runs on dozens of different platforms, and is used in all sorts of different ways. Keep that in mind when writing a library.

  10. If you have multiple files, allow your user to define a base dir. (aka don’t make assumptions #1)

    This is trick from Smarty that was pointed out to me.

    If you have a core library file (e.g. that will be including support files don’t make assumptions about the PHP include path on the various machines where your library will be installed.

    For example assume there is a constant MAGPIE_DIR defined then you can include the support libraries with:

    require_once( MAGPIE_DIR . '' );
    require_once( MAGPIE_DIR . '' );

    This allows code that uses your library to inform your code about the local environment, rather then forcing your client code into contortion to match your expectation of how a PHP install should work.

    MAGPIEDIR (or YOURLIBRARYDIR) might be set up with code like:

    if (!defined('DIRSEP')) {

    if (!defined('MAGPIEDIR')) { define('MAGPIEDIR', dirname(FILE) . DIR_SEP); }

    Which fill set the MAGPIE_DIR to the current directory (useful as ‘.’ isn’t always in the include path) unless you override it with a statement like (for example):

    define('MAGPIE_DIR', '../../magpiefiles');
            (More on using constants for configuration later.) 
        If you're using a semi-obscure PHP extension test that it has been compiled in.  (aka don't make assumptions #2)
            This <a href="">bit me hard</a> when developing MagpieRSS.  I add supported HTTP gzip encoding, and suddenly for a small number of users Magpie starting failing.  This was a surprisingly difficult bug to track down, I recomend avoiding it all together.  This is what PHP's <code>function_exists()</code> function is for.
        In code that uses gzinflate I might add a conditional like
        <pre class="code">

    if ( functionexists(‘gzinflate’) ) { …. } Or at the beginning of the Magpie RSS parser I check to make sure PHP has been built with XML support with

    if (!functionexists('xmlparsercreate')) {
     ... trigger error ...
  11. Don’t pollute the global namespace

    All functions share a namespace in PHP. What that means is, if I have a parsefile() function in my library, and you have a parsefile() function in your library PHP has no way of telling them apart, and we’ve got a serious problem. Classes help with this.

    Another option is to prefix the functions in your library with a common string. Steve does this with Feed on Feeds, prefixing all his functions with fof, e.g. parsefile() becomes fofparsefile(). Cuts down on conflicts, and increases readability.

  12. If you use database tables allow a table prefix. (aka don’t pollute the other global namespace)

    Most libraries aren’t going to work directly with a database, that is the province of applications usually, but if you are consider allowing the user to configure a table prefix, much like the function prefix from the previous tip. Many users are on low end hosting platforms with only a single MySQL database, this creates another global namespace. If my library has a user table, and your library has a user table, and we have different schemas (almost a guarantee) then we’ve got a problem.

  13. Provide a well designed, object oriented interface to your library, that follows the above rules.

    This is outside the scope of these tips, but see the following corollary.

  14. Provide a functional, PHP-like interface that builds on your OO interface.

    PHP is not a language for building airy, abstract object hierarchies. It is a quick and dirty language for throwing together webpages with a minimum of fuss. While its important to provide the more elegant interface for your advanced users, and to encourage proper design, the majority of your users are going to want something simpler.

    With Magpie I provide an object oriented RSS parsing class. I also provide a simple, rssfetch() one function front-end that is designed to be used directly from within a PHP page.

    My design consideration for rssfetch were fetching remote files is time consuming, and parsing an XML file can be resource intensive. In most languages/environments you would setup a cron script to run in the background handling these tasks, and spitting out HTML fragments. This is not very PHP-like, and often beyond the technical ability of many PHP users. (or beyond what is offered in their hosting environment). So rssfetch transparently uses PHP’s serialize and unserialize to cache the results of the time/resource intensive calls, and serve subsequent calls quickly.

    This makes it very easy for the end users to do the right thing, while writing simple, idiomatic PHP. I think this is very important for writing useful PHP libraries, and is one of the challenges that comes with the territory.

  15. Configuring the functional interface using defines.

    (aside: by functional we means as opposed to object-oriented, not as opposed to non-functional or dysfunctional)

    Choose intelligent defaults, and provide a simple default means our functional interface should “just work” for many people. But when it doesn’t, it should be equally easy to configure without cluttering up the API.

    What I’ve done with Magpie, and its worked well, is extend the technique used in “setting a base dir”.

    Conditionalize your library behaviour on a set of constants (e.g. MAGPIEUSEGZIP, and MAGPIECACHEON). Document these constants. People can now change the behaviour of your library with some simple statements at the top of their PHP, like:

    define('MAGPIECACHEON', false);  // turn off cacheing
    Then the first thing your function should do is call an init() function which sets up those intelligent default we talked about:
    function init () {
        if ( defined('MAGPIEINITALIZED') ) {

    if ( !defined('MAGPIE_CACHE_ON') ) {
        define('MAGPIE_CACHE_ON', true);
    ... other constants ....
    define('MAGPIE_INITALIZED', true);


  16. Provide examples

    Always a good idea, but particularly important when distributing PHP libraries. Don’t assume people will read the documentation, or if they do your programmer-esque understanding of your tool will be meaningful to them. What will make sense is example.

  17. Provide examples, carefully

    Be careful what your examples look like because whatever you do in your example is what 90% of your users will do in their scripts.

    Test your examples or your support queue will fill up with people who cut and pasted your code and it isn’t working for them.

    Make your examples as attractive as you can while still being simple, otherwise you’ll be forced to look at your ugly HTML all over the web.

    Show examples that show proper use of your library, including best practices like error handling. If your examples show how to use a feature it will be used, if they don’t, them most people won’t use them.

  18. Document

    Document document document. Provide inline document. Provide a README. Provide a FAQ. Provide a website. Provide hints of where to go looking for more info. Hints like “this class is used by rssfetch() you can stop reading now if you just want to use the simple interface” can also be useful. (of course don’t sound too smug about it, as chances are people are there trying to find one of your bugs)

    Running code is good documentation.

    If you’re going to provide code snippets make them longer then seems necessary as people will often have different instincts about what should come before and after the line in question. This is again the joy and trouble with providing a PHP library.

    I personally like “cookbooks”, a hybrid of a FAQ and running code samples.

  19. Use it Yourself, Use Consistent Names, Plan to Expand

    And just to re-iterate a few of Moran’s suggestions

    Until you really use your library you’ll never know how well you’ve succeeded. When you write a library you shouldn’t conceive of yourself as the only user, but certainly one of the users. Also developing good relationship with people who use your library will cause it to improve dramatically.

    If you name half your methods getRSSFile() and the other half getcache_dir() your users (and yourself in a few months) will be confused, and your code will look messy.

    Moran says, “Never return a single value when you can return an array. Never return an array when you can return an object.”

    I think that is overstating the case, often you’ll want to return a single value for simplicity sake, but take into account when you might not want to. Often returning an object will make the most sense, as long as your clearly document how to use the object.

PHP needs libraries

PHP can be a frustrating language to work in, but its also very rewarding. One of the things I find most rewarding about it is the chance to make an impact, and the easiest way to do that if to release well written, well architected libraries. The community is starting pull together and provide some of this in form of PEAR and PECL, but those projects have a long way to go before they are well documented, easy to use and easy to install. In the meantime you can fill a critical need.

Resisting Temptation, Educating, and Refactoring

Because this lack of libraries is a deep set cultural problem you’ll often find users writing you asking you to add feature X, or feature Y to your library to make it work more like they want their application to work. Remember you’re doing one thing, and doing it well. This is a chance for education. Explain that you’re building a library and the features they’ve asked for are more suited to an application. If you’re feeling like you have the time, or are particularly generous, or if a request comes up over and over consider adding a code sample to your examples to show how to fulfill that particular feature request. Among other things you might find its harder then it should be, and prompt a change in your library.

Thanks to Steve, Martin, Scott, and Evan for their feedback and suggestions.


September 5th, 2002

In our modern, mediated, sterile, controlled life there is little room for magic, the surreal, fantasy. Which is why I’ve alway appreciated flying out of Boston’s Logan International. Logan’s tight affinity with the T is the best airport/subway integration I’ve expirenced in the US. You hop on the Blue Line, and get off at Airport stop, simple. But it goes beyond that. As you follow the twisting corridors of State, or the narrow stairways of Government Center, like Alice, down the rabbit hole, you follow the signs that say “To WONDERLAND ->”.

If you are flying away to remote tropical island (say Vieques for a long weekend with your significant other) this seems a poetically appropiate grace note in a world much lacking in grace. If, on the other hand, you are flying to Detroit, at least its good for a chuckle. Either way, it lifts the flagging spirits, weighed down under a heavy load. (usually my Gregory pack)

Speaking of Detroit

By the way, if you are flying to Detroit, say as a 50 minute layover on your way to San Francisco, do yourself a favor and get off the airplace and explore this little fairytale airport. The very image of a major modern airport, white steel girders, clean, airy, giant windows. The first unusal thing I noticed was the Tomorrowland inspired red monorail that glides along quitely above the concourse. Confused about how to board, I walked to the center of the terminanl where I found a reflecting pool.

The Living Water

Raised several feet into the air, upon a circular ~30ft diameter black marble pedestal, a thin layer of water rippled across its surface refracting subtely among the stainless steel divots scattered randomly acrss the surface like stones in a zen garden. As I contemplated its quiet nature, the pool transformed into a fountain, one of those ultra-modern ones, perflectly regular strands of waters arced from the divots into a forthing center. I tried to stifle my disappointment, and appreciate this new form, but the fountain transformed again on me, the water now sputtered out in quick bursts, creating short cylinders of water that arc through the air in a school of confusion, like a school of drunk flying fish, and seem to slip beneath the water in the frothy center. Its hard to explain how these water elementals lifted my spirits, their joie de vivre was so obvious for their short live span, and who knows what happy world they disappear to down that center well.

The spigots again on their steady streams, creating solid bridges of water, but shut off again as quickly as they turned on, creating the feel that the water has been snatched by something in that dark center (which is now, in my mind, fully equipped with an active underworld) and is being reeled in quickly, the end deattached for its source whips through the air. The quiet reflecting pool repears.

Tomorrowland, and the People Mover

Walking on, happy from my encouter with the fountain (I adore fountains), I found: edible Chicago style pizza, the far end of the terminal, and an escalator up to the monorail. At the top of the escalator I find a platform equipped with digital readout telling me when a train will arrive ( 0:48 minutes) and a map that shows me where in the system each train is.

The train glides smoothly in the station, lining up just so with the double class doors that separate the passenger from the tracks. No danger here of being pushed from the a busy subway platform where you meet ignominious death by rats, rat poison, the third rail, or an oncoming train. The doors open, a voice annouces our desitination, and we’re off. The whole system is pleasingly automated, the acceleration, deceleration, opening and clossing of the doors, all have that graceful precision you only get from a computer. The tracks widen to 2 lanes just long enough to allow for the trains to perform a timed dance of gliding past each other as they move in opposite directions, before continueing their monorail existence.

Illusions and Disillusions and Henry Ford

I ride the train back and forth a few times, back and forth between its three stops, feeling like the kid who spent hours riding up and down the day JC Penny’s opened with Santa Cruz’s first escalator. I’m torn though. Because while part of me loves this slick futuristic monorail, part of me resents that its just a toy. The train only has 3 stops, and uses a simple cable and pulley system for its locomotion. Far from being the basis of a modern transit system, its more like the kiddie rides at the fair, you know the ones you have to be under 48 inches to ride.

Then it hits me, how odd this paen to public transportation is in airport that also includes the “Heny Ford Musuem Shop”. We are in Detroit! Suddely I look around expecting to see little personal golf carts for each person, traffic lights, traffic jams, and smog. The bitter irony of a cable powered people mover in the home town of the very industry that spent millions of dollars killing off public transportation including turning the only real cable powered train system (SanFran’s cable cars) into a tourist trap. The shiny red space age train is just a gloss PR puff piece by the car industry, cute but empty and calculated.

Tagged: Uncategorized , , , , ,

A Personal History of RSS

April 17th, 2002

We recently launched a new feature on the Indymedia Global site. Built on top of RSS, the features newswire is an aggregation of the hilighted stories (features) from the local IMCs.

There has been a large amount of contentious discussion about this feature, and its been very interesting. It has proved to be a chance for IMC to revive, and reaffirm our institutional memory, the quasi-verbal tradition that binds us together. Many others have responded to other points superbly, however I felt that I should respond to the claim that, “XML/RSS is corporate plot to take over the world”. It was claimed that RSS is some sort of proprietary technology maintained by AOL/TimeWarner, and that we were forcing people to abandon the road of Free Software to come mingle their stories with ours. I have a long (if not very active) involvement in RSS, so I want to respond.

First, the link Arc sent, RSS: Lightweight Web Syndication is a good starting point, Rael is very heavily involved in the current state of RSS, and is generally an excellent and insightful tech writer. Rael, like all historians, is also trying to push a particular viewpoint with his history. He is trying to build legitimacy for his idea of a modular, RDF compliant RSS. So here is another prespective, a much more personal, and less eloquent one, perhaps.

My colloquial history of RSS

I first saw RSS mentioned on Slashdot in early 1999, I think around January or so, as an Ask Slashdot story about the new alpha Netcenter, Netscape’s late entry into the portal game. Netcenter was the first, last, and only cool portal. It acknowledged that people might want content beyond the generic fare of AP and Reuters (something Yahoo still doesn’t offer) So it invented a format to allow headlines to be syndicated into its Netcenter Channels. And they added MozilliaZine and Slashdot.

So someone asked, “Could we create our own Netcenter channel?”, and the creator of Netcenter RSS responded in a comment explaining the process (which was still totally informal, as it was pretty much just this one guy doing it) And so light weight syndication took off. At we had just recently started re-posting DAMN articles, and a few of our own pieces, and so we whipped up a RSS feed, and submitted it to Netcenter, and it was included. So now the really amazing content from the late and much lamented Direct Action Media Network was showing up on this mainstream corporate portal.

And then Slashdot decided they wanted channels, and they called them Slashboxes, and put CowboyNeal in charge (who was accepting if flaky) and the whole network of small self-publishing sites, sharing content and traffic, which has grown exponentially recently to include the bloggers was born.

This is all pre-AOL acquisition of Netscape. AOL bought Netscape, and gave Sun all the good stuff, keeping Netcenter, and the browser for itself. Some people speculated that they bought Netscape for Netcenter. That might have been, but one of AOL’s first acts was to shut down the super cool Netcenter, and replace it with a generic portal. (probably bought from Infospace)

I don’t remember when I first heard about the syndication mailing list, but I sure jumped when I did. We had been talking for a while about how to create a syndication network to share the content from, DAMN, and Zmag in a meaningful way, and here were some of the sharpest people doing this stuff all haggling about syndication.

Well I thought the list was a flop. Dave Winer had not mellowed down into the quiet, open minded buddhist monk we know today. And he browbeat people into abandoning the original pie-in-the-sky ideals of RDF/XML and turning RSS into the Userland format. RDF being TBL’s attempt to build some tools to make the web a collection of rationale information, where your access to being heard is dependent on the quality of your information.

And thats how things stayed, we kept talking about building this syndication network, without ever having time to do it, and RSS kept puttering along, and I kind of lost track of it. (IMC happened, and there went the last moment I had to stop and catch my breath for like a year)

And when I saw Rael’s first post about modular RSS, RSS 1.0, an idea to get back to the original ideas about RSS being an open format, and RDF, and adding XML namespaces, to allow people to innovate, and do their own thing, but still work together. And it used Dublin Core, and it was elegant, and his first act was to say, I’m just playing with ideas, lets make an open mailing list, and all talk about this for a few months, and see what people think of it. And so it went, RSS 1.0 evolved in an open fashion, geeks flailing in the dark for a form of consensus, they dealt with some vicious attacks from the Userland old guard, and eventually built a new standard, that encouraged collaboration, but also allowed people to do their own thing.

And in the meantime blogging took off, the personal publishing phenomena which is just starting to really catch the mainstreams eye, and has much in commom with Maff’s Hilights proposal, and Dru’s Open Publishing proposal, and the idea that the web was a conversation began to be normal again.

So it seems to me, that to say RSS is a standard maintained by AOL/Timewarner is incorrect, and uninformed. To insist so violently upon it smacks of disinformation to me.

On Indymedia we generate 3 RSS feeds, v.9 the Netcenter version, v.91 the first “userland” flavor developed on the syndication list, and v1.0 hammered out in public, by consensus. The features newswire is uses the version 1.0 of RSS, though admittedly not for political reasons, but because its more richly descriptive.

Tagged: Uncategorized , , , ,