| |
 |
Friday, March 15, 2002 |
|
Messages to spaces is publish/subscribe
Rick@Leaders.net:
Posting Messages into Spaces [via Jon]: This is a new way of thinking about communication. It is akin to posting to listservs where your message goes out to a group of people. Yet, blogs like this and "messages into spaces" are more akin to speaking to nobody in particular yet at the same time to those who are specifically interested in this subject either now... or at some point in the future. [Rick@Leaders.net: All Told]
Exactly. It's just like publish/subscribe, a technical architecture for many-to-many communication.
6:49:58 PM 
|
|
|
Bite-sized nuggets
Rahul Dave wrote to suggest a simple solution for making items easy to scan in RSS readers: truncate the [description] to a few hundred characters. Today I subscribed to a channel that does this. Look how elegant the effect is:
Rahul's idea put into practice
3:22:37 PM
|
|
|
Extensibility and critical mass
Simon Fell on extensibility:
Coping with Change [Sam Ruby's Radio Weblog] More good stuff from Sam, he also points to this post about extensibility. This is why I prefer SOAP over XML-RPC and RSS 1.0 over RSS 0.92, because they are extensible in a non-centralized manner (using namespaces). For example, a while back I wanted to syndicate information about time based events, RSS 1.0 allowed me to compose in the additional metadata I wanted (and in fact, I was able to re-use some standard metadata defined by Dublin Core), whilst RSS 0.92 required me try and get the spec rev'd, and whilst there is now a RSS 0.93 spec, its appears to be pretty much dead in the water. [Simon Fell]
Boy, is this ever a touchy subject. I understand and appreciate both sides of the issue. Extensibility does matter, enormously, but not until critical mass creates the environment in which it can. For what it's worth, I believe both of these premises to be false:
COM, for example, was non-extensible (as Sam defines it), yet it reached critical mass. Now MS has the luxury of replacing it with a more extensible infrastructure.
Meanwhile, the landscape is littered with the corpses of wonderfully extensible systems.
Could COM and .NET have happened in one iteration? It's an interesting question. Perhaps it would have been possible to make 1990s-era COM interfaces be a degenerate case (singly rooted in an MS namespace) of something more general, such as is now emerging. And, to do this in a way that wouldn't have slowed anybody down.
We can't repeat that particular experiment. The tradeoffs being made now between extensibility and critical mass are happening in a different world. Nobody knows, for sure, where the right balance point lies.
One thing is sure, though. Until and unless critical mass is achieved, we are just angels dancing on the head of a pin.
2:03:37 PM
|
|
|
JavaScript, Perl, Python, .NET
Peter Drayton on JS.NET:
> I believe there is a market for a language much simpler than VB.NET.
For this, I suggest JScript.NET, which is also included in the .NET Framework. The funny thing is, while JScript is a relatively simple language, the JScript.NET compiler is actually very sophisticated, since it has to support late binding, prototype classes, typed and typeless variables, dynamic evaluation and a slew of other 'scripting' features. Basically the compiler does all the requisite magic to present a very friendly, simple face to programmers, while doing all the underlying goo needed to make these semantics work in the CLR. [Peter Drayton]
I just tried Peter's example:
var query = new ActiveXObject("IXSSO.Query");
query.Columns = "directory,filename";
query.Query = "@filename=*.txt";
query.Catalog = "System";
var rs = query.CreateRecordSet("sequential");
while (!rs.EOF) {
print(rs(0)+ ""\\" + rs(1));
rs.MoveNext;
}
Interesting. Could the same principles bring this Perl/Python research to fruition?
1:08:32 PM
|
|
|
Writing in Mozilla
I've been waiting for a very long time for Mozilla to become dogfood. The good news is that 0.9.9 finally is. The bad news is that my breath is going to smell like dogfood for a while. But that's OK. There was a ton of stuff in Netscape 4.x which was never fully understood or appreciated. As Mozilla resurfaces and extends that functionality, it's important to understand and document what's happening.
From my perspective, some pieces of Netscape/Mozilla that seem ancillary to others are of vital interest to me: the mail/news client, and the message composer. That's because I've always thought two-way communication, not one-way publishing, was the true purpose of the web. Messaging tools and environments were always at the heart of this, for me. The Netscape 4.x suite of apps -- browser, mail/news client -- made remarkable advances, more than is generally understood or appreciated. The vision, never fully realized, was to unify the browser and mail experiences. But when the air went out of the balloon, that hadn't happened. It still needs to, and eventually it will.
There's explosive activity in blogspace right now. Mozilla can add even more fuel to the mix. I'm writing this essay in Composer, and will post it through XML-RPC to my blog, courtesy of Hannes Wallnöfer. The same Composer is used in the Mozilla mail/news client. There's tremendous synergy possible when a standard (and sufficiently powerful) writing tool is available in both domains. Of course, that was as true in 1996 as it is today.
This Composer is a little better than it used to be, but it's not five years better, yet. I think that's because improving it never seemed to matter to many people. Writing email was something everybody did, but writing email that's rich with images, links, tables, vector images, and equations -- in other words, writing email on a universal canvas -- wasn't something people expected to be able to do at all, never mind easily and routinely. Writing for the web was something some people did, and those people would have liked to be able to write on a universal canvas, but didn't demand it loudly enough.
The blog phenomenon, I hope, will finally push things over the activation threshold. If so, a number of latent issues will resurface. I've dealt with a lot of them before, and plan to write about them again as they come up, in various venues including this one. Here are some of the issues I see on the horizon:
-
Hypertextual writing. The experience of writing this document in Composer can improve in limitless ways: drag-and-drop link and image creation, smarter table editing, CSS stylesheeting, and much more. Implementing these things is hard. Doing it in a way that makes sense to users is infinitely harder.
-
Compound documents. Netscape 4.x did a clever thing. Its cid: protocol enabled messages containing images to refer internally to those images. This bundling effect is still missing from the web. Writers new to Radio can too easily create documents whose parts don't hang together. Fear of embarrassment prevents many from trying to write compound documents. This fear needs to be eliminated.
-
XML metadata. After I post this essay, I'll use Radio to add metadata (title, link). Happily, that shouldn't be necessary for too much longer. But as Sam points out, things keep changing. Our writing and reading tools need to empower users to create, exchange, and use metadata-enriched documents -- and to do the enrichment themselves.
-
Identity. As the problem of identity fraud worsens, the need for ways to assert identity becomes clearer. Here too, mechanisms have been available for years, but not widely used. Mozilla's mail client almost (but not quite) recreates the S/MIME capabilities that Netscape 4.x had in 1996. As soon as I can get a Thawte or VeriSign cert to work in Mozilla, I'll be able to use it to sign mail, as I routinely do. But the signing interface that's available in Composer, when writing email, isn't available in the instance of Composer I'm writing in now. I think we'll need to unify identity management across all our methods of communication. Doing that in a way that makes sense to people, not geeks, is the challenge.
To the Mozilla community: thank you for making, and eating, the dogfood. Rewriting was a huge risk. Even though Joel said not to, what's done is done. Time may have been lost, but most of the really important issues are still on the table waiting to be solved. It's not just about the browser, not by a longshot. People are writing more, and differently. It's part of a trend that brings the web right back to its roots. For my money, the tool through which those keystrokes flow is vastly strategic. Is this going to be an important one of those tools?
11:41:31 AM
|
|
© Copyright 2002 Jon Udell.
|
|
