Whatever else Jesus was, he was almost certainly a radical.
He challenged the mainstream religious authority.
He challenged the mainstream governing authority.
He challenged the mainstream attitudes toward those who are not in the mainstream.
My wish for us all is peace and true prosperity.
May we all take one radical step in that direction in 2004 and we'll be more than a billion steps closer.
Mark Baker makes an interesting distinction in my wRESTling with tuple spaces...
Patrick seems stuck with how to reconcile his position that generic abstractions are a good thing, but that systems should be built independent of the protocol. Note to Patrick; this is all well and good for transport protocols, but application protocols define the abstraction; for them, protocol independence requires that you disregard that abstraction.
This distinction of transport protocols vs. application protocols is exactly what I am wondering about REST. As I read the definition of REST, the architectural style being described is for a transport protocol rather than an application protocol. Not much is said really about the behaviors of the client or the server. Even when you bring HTTP per se into the definition of REST, Fielding makes a somewhat confusing statement about transport protocols...
HTTP is not designed to be a transport protocol. It is a transfer protocol in which the messages reflect the semantics of the Web architecture by performing actions on resources through the transfer and manipulation of representations of those resources.
Is it a transport protocol or not? Let's ignore that and pursue the part about "performing actions on resources" because that *does* seem to be about an application protocol. Fielding continues...
It is possible to achieve a wide range of functionality using this very simple interface, but following the interface is required in order for HTTP semantics to remain visible to intermediaries.
And so this is where I begin to have problems with REST, as I read it, as an application protocol for distributed system coordination. The problem is not that it is inappropriate, but rather that it is too vague.
I don't mean "vague" in a derogatory manner. What I mean is exactly what Fielding writes, i.e. it is possible to implement a wide range of functionality using this very simple interface.
How is this different from the tuple space interface? I have written, and many others better than I have written, that it is possible to implement a wide range of features using the very simple tuple space interface.
The difference is this: the HTTP interface is vague and the Linda interface is specific. Linda has precise, simple semantics. The possible range of behaviors exhibited in Linda-based systems benefit from being layered on *top* of those precise, simple semantics.
HTTP, on the other hand, has to be *elaborated* into something more specific in order to have a useful meaning as an application protocol. WebDAV is an example of such an elaboration.
Every web site that implements custom behavior using forms with GET or POST is an example of the open ended nature of HTTP per se. The architectural style of REST supports the HTTP transport protocol underlying these forms moving across the web, but the application protocol, that is, the behavior of the forms on the client and especially on the server is defined (at least in code) by each specific instance.
Distributed systems wishing to use HTTP, or more generally REST, to perform coordinated work will therefore require some more specifically defined application interface than that provided by REST, or that provided by HTTP.
WebDAV is one option as stated already, and it is proven to be viable in some specific cases. I don't believe the full range of systems that can be usefully built with WebDAV has been exhausted. By the same token, neither do I see a lot of evidence of that range being nearly as broad as that of Linda tuple spaces.
Vanessa Williams provides an elaboration of HTTP for a tuple space application protocol. As I understand REST this should therefore provide the application protocol of a tuple space on the architectural style of REST using the HTTP transport/application protocol mix. In this case the advantage of using REST and HTTP is supposed to be found in the hardware and software that would already be in place between the client and the server.
I think and hope this is fairly accurate. I am eager to be clued in further by Mark and others. I am still unsure that this advantage is significant over a less pure elaboration of HTTP, as in XML-RPC or the arguably more RESTian SOAP. I think there is a lot to be said for something else altogether as a transport for tuple spaces, in particular Jabber or perhaps Spread. The bottom line is the usage models of distributed systems coordination would benefit from a well defined, simple, axiomatic application protocol, but the best transport protocols *will* have to evolve just because the usage models themselves will have to evolve. For all but a handful of services (e.g. Google), they just may act nothing like today's web.
Queries: reportedly, Adam Bosworth said at the XML conference...
"I don't know how we're ever going to truly optimize these queries."
Before we worry about that, though, we should consider how the average user is going to form those queries. The last twenty years have made great strides in forming SQL queries for numerical data analysis. The models underlying those queries fortunately support both the relatively non-technical users who wish to form them as well as the highly technical adminstrators who wish to optimize them.
What kinds of queries do these users wish to form? What are we trying to optimize? What relationships will these have with current typical business analysis?
Will we wait twenty years for the evolution to settle into a widely used winner?
Update: I almost forgot Doug Lea's thoughtful design and implementation of a collection package, which predates the java.util collections. That specific link will take you directly to his wisdom on designing type checked immutability. (Which makes me wonder if Microsoft has hired him yet too?!)
Greg Schecter writes about the Changeable class. Not knowing much about the implementation this seems like a reasonable concept. (EmeddedChangeableReader sounds like it might be a bit over the top, but I don't know.)
Compare this to Object.freeze in Ruby. The Ruby implementation appears to be simpler, but the overall lesson I think is this: what we have in the Changeable class is more evidence of Java-like languages struggling with their underlying dynamic tendencies.
Inside every statically type checked language there is a dynamic language struggling to get out.
The simple statically checked approach is to create a class without mutation, e.g. Brush, and then add mutation in the subclass, e.g. MutableBrush. Another approach is to simply throw an exception in a method that would otherwise cause a mutation without any system-wide designation in the code. See the Java Collections API for example. In particular the unmodifiableCollection static method and its siblings for List, Set, etc.
Then again there is the option of just allowing mutation for all instances even when it's not expected. One of the first actions I took in my first Smalltalk system (the Tek 4404) was to change Black to White. Oops. Fortunately although Smalltalk has a persistent image, it's not difficult to back out of the change.
Jon Udell writes about XML for the Rest of Us wherein Adam Bosworth writes...
"The relational database is designed to serve up rows and columns," said BEA's Adam Bosworth in his keynote talk. "But our model of the world is documents. It's 'Tell me everything I want to know about this person or this clinical trial.' And those things are not flat, they're complex.
I agree with the idea of semi-structured searching and manipulations. But I don't expect anyone would deny we still need traditional (e.g. business) calculations and those will be well served by more structure than less. I'd like to see a more direct XML Query and SQL comparison. As it stands, I'm being led to believe I'll should use XML Query (i.e. something with XPath-like stuff in it) for doing non-numerical property-tree searches over data that has been or could be expressed in an XML text; but I should use SQL for doing relationally flat table-column calculations over data that has been entered into a relational database.
There is a merger out there somewhere that I'm not seeing, or maybe just an example of what such a merger might look like.
Watching this PDC session on InfoPath is worth the time. Better than previous demonstrations and white papers I've read, especially if you looking for somewhat technical information for InfoPath in the context of a modern Microsoft-based IT shop.
A collection of first computer stories relayed by Dan Gillmor.
My first computer was an IBM 5100. Flip the switch up, you're running BASIC. Flip the switch down, you're running APL.
I'd hardly call it a portable computer though. The box was not even as mobile as those "luggable" computers like the Kay Pro from a few years later.
http://www.publicradiofan.com has a listing of, well, audio links to what's on public radio right now.
Great news from Harry Shearer...
Now, some real Xmas cheer: many of you have been asking when you can buy my film "Teddy Bears' Picnic" on DVD. The answer, apparently, is this February. Be warned, you may have some trouble finding it, since, as the result of a monthlong battle lost this week, the cover art on the box will more closely resemble Porky's 4.
This is merely proof that, while it's now easier to make a movie outside the Hollywood mainstream, to get it seen one still has to run the usual gauntlet of Visigoths. These particular barbarians, in a nice twist, are Canadian, and they appear to believe that the target audience for this movie is teenage boys. I'd share the art with you, but I promised a low-impact blast, so take my word for it--the bikini-clad blonde who dominates the cover art appears nowhere in the film.
If you'd like to send a greeting to the primate who insists on this approach, his address is: rmanis@thinkfilmcompany.com. Yes, thinkfilm. When your business is irony, even that comes back to haunt you.
Phil Windley expresses an interest in tuple spaces and points to an item that spells out in some detail why I am still unsure of what ReST really means at a deep semantic, implementation, and performance level. I wrote about this in a couple of (admittedly superficial and this is more of the same) items in April 2003.
Whether using "pure" HTTP, or SOAP, XML-RPC, or Jabber, (or SOAP over Jabber, XML-RPC over SMTP, SOAP over BEEP over HTTP, or... even RSS, RSS-Data, and polling or cloud APIs as part of the transport) the key is to distinguish transports from actions.
A tuple space (or XML space, where the tuples are represented as XML text) for distributed, asynchronous computing can be (and should be) implemented on top of multiple transports. The important aspect for applications are the actions (tuple space semantics). The implementation and performance of the transports can (and should) evolve independent of the simple semantics of tuple space actions.
Above the simple actions, independent of the transport implementations, the simple tuple space actions can be combined into various kinds of databases, queues, exchanges and marketplaces that we really want to focus on evolving in the first place.
Have you noticed that the most likely source of technology expertise, IBM has simply refused to provide a Linux Desktop? With all of their Lotus applications neatly running on their own UNIX products, they won't let you have them on Linux. Instead, they suggest you purchase Windows XP Professional.
The internal strife existing at IBM over producing a Linux desktop has the potential to hurt IBM's business model. A powerful internal software organization wants to grab server market share from Microsoft without disturbing Microsoft's desktop. Anyone inside IBM that mentions a Linux desktop has the potential for losing their job. While few people at IBM know what exists outside the company, the powerful software group may have top executives walking the same plank as the rest of us if Microsoft remains the only Intel desktop platform.
While the software people at IBM have their heels dug in, they may find out that their Web Services strategy based on Java has no place to go. Sun may not have put IBM in "Check," as Scott McNealy has put it, but Sun's Java Desktop System definitely places IBM in a Microsoft dilemma. IBM will have to decide if they'll continue to provide Java Web Services and find a desktop to accommodate it, or watch their Java developers transfer their code to Microsoft's Java Language Conversion Assistant.
It's true, and in the morning I felt kind of bad. But it was for the good. I've done it in the past, but this time it was coldly calculated. Please read on...
Actually when it comes right down to it, I don't care what happens to Visual Studio. I also don't care what happens to Emacs. VS will continue to improve, but moreover it will continue to be hugely popular no matter what. Emacs has the audience it does, and will probably not improve beyond its current state, because it is in itself an axiom. Probably it's appeal and usage characterisitics will remain about where they've been for the last twenty years.
So why did I use Don Box?
More people than I could ever hope to draw on my own have had a chance at least to read the story about Emacs and the secretaries in the 1970s. Was this story really intended to promote Emacs and to benefit VS?
Not really. I saw the opening and ran for it. Here's the message: the Longhorn preview takes over five gigabytes to install. How much of that is for the typical user?
Very good arguments could be made that all of it will eventually trickle down to the non-technical user. There is no way I could or would argue against that.
But in the 1970s a few typical secretaries had a simple tool for helping themselves, the same tool most programmers have intimidated each other from using even as an influence. In the 1980s typical non-technical users were building multimedia applications using Hypercard. Emacs and Hypercard together take a miniscule fraction of the installation space and still a small fraction of the intellectual power required for computing with XML, DOMs, XAML, and WS-xxx. Are the secretaries going to be doing this in Info Path?
In all of these five plus gigabytes of impending computations, what are we doing for the typical user or even the non-technical MBA? Maybe this was an inappropriate way to use blogspace.
Don Box wishes he could be disagreeing with James Robertson's observations on Visual Studio Dot Net, but apparently can't. Here's what makes the difference.
I would consider any advice Don brings from Emacs an improvement for VSDN. But the fundamental difference is also the fundamental failing of not just VSDN but practically every IDE I have seen including the vaunted IDE for Java using Eclipse.
The irony is the term "Visual" because VSDN is a visual nightmare. The beauty of *most* uses of Emacs (remember Emacs is a flexible tool-building platform like Eclipse, except simpler and more expressive) is the visual simplicity and just-in-time functionality. Where VSDN gives you panels, panels, everywhere panels of things to do and be concerned about, Emacs gives you an editing buffer. Everything else is a keystroke or menu click away. All the power of VSDN and more is waiting for your call to action, but visually you are "just editing".
Let's recall this story from the 1970s about secretaries (as they were called then) using Emacs, essentially the same Emacs you're using today. (You *are* using Emacs, aren't you? For shame!)
...programming new editing commands was so convenient that even the secretaries in his office started learning how to use it. They used a manual someone had written which showed how to extend Emacs, but didn't say it was a programming. So the secretaries, who believed they couldn't do programming, weren't scared off. They read the manual, discovered they could do useful things and they learned to program.
Would we ever read a similar story about VSDN? For want! Not by the 2070s.
One ring to bind them all. Emacs Semper Virens.
I just picked up Game Programming with Python by Sean Riley. Sean is also the author of the PyUI user interface framework. He explains and uses PyUI in the book as well.
Just thumbing through the book, I would give it a thumbs up. It looks good and I hope it pans out. No pun intended.
Before we get too caught up in the capture of a dictator we (the U.S.) supported for decades, let's take a tally of the others still in our (the U.S.) favor.
In two fine speeches recently, President Bush made it clear that autocratic regimes in the Middle East, including U.S. allies Egypt and Saudi Arabia, need internal reforms to stop churning out terrorists. Somehow, though, he forgot to mention Azerbaijan and Uzbekistan.
If the president's ratings go up based on the recent capture of a former ally now out of favor, should that be considered a mandate to terminate relations with these others? Or does the administration itself suffer from "moral relativism"?
From Brad Neuberg, OnJava, an insightful abstraction of sockets on p2p on sockets...
P2P Sockets effectively hides JXTA by creating a thin illusion that the peer-to-peer network is actually a standard TCP/IP network. If peers wish to become servers, they simply create a P2P server socket with the domain name they want, and the port other peers should use to contact them. P2P clients open socket connections to hosts that are running services on given ports. Hosts can be resolved either by domain name, such as www.nike.laborpolicy, or by IP address, such as 44.22.33.22. Behind the scenes, these resolve to JXTA primitives, rather than being resolved through DNS or TCP/IP....
The P2P Sockets project already includes a large amount of software ported to use the peer-to-peer network, including a web server (Jetty) that can receive requests and serve content over the peer-to-peer network; a servlet and JSP engine (Jetty and Jasper) that allows existing servlets and JSPs to serve P2P clients; an XML-RPC client and server (Apache XML-RPC) for accessing and exposing P2P XML-RPC endpoints; an HTTP/1.1 client (Apache Commons HTTP-Client) that can access P2P web servers; a gateway (Smart Cache) to make it possible for existing browsers to access P2P web sites; and a WikiWiki (JSPWiki) that can be used to host WikiWikis on your local machine that other peers can access and edit through the P2P network. Even better, all of this software works and looks exactly as it did before being ported. The P2P Sockets abstraction is so strong that porting each of these pieces of software took as little as 30 minutes...
Russell Levine writes in the Business Integration Journal about the Myth of the Disappearing Interfaces. If you work in IT, have been involved in some EAI projects, and are a relatively critical thinker, then there probably is not a lot of new information for you. However the piece serves nicely as an antidote to the run-of-the-mill "Service Oriented Architecture", well, pablum.
More good information can be found at Doug Barry's site. Almost too much at once without a trail guide. Better than run-of-the-mill, without a doubt.
From Russell:
There you go.
Jon Udell...
So what's all this got to do with XML? If you buy the notion that we are projecting ourselves into networked information systems, then we can't only focus on how processes and data interact in these increasingly XML-based systems. The quality and transparency of our direct interaction with XML processes and data -- and with one another as mediated by those processes and data -- has to be a central concern too.
When I think of XML, two things come to mind. First, I think of the movie Brazil, because XML is still this grab bag of stuff that happens to share one thing in common, angle brackets.
Second, I think of David Letterman's bit he calls "Is this anything?"* --- We expect XML to be something, anything, more than a grab bag of stuff that shares something in common beyond angle brackets.
A third thing comes to mind: the black knight in the Holy Grail, after all his limbs have been cut off. XML is utterly helpless in and of itself. It's everything *around* XML that has value, most of which are hindered by XML per se, not aided.
One of the more interesting projects I have come across in a while, OpenAugment...
The OpenAugment Consortium is a not-for-profit open source corporation dedicated to the preservation of the Augment legacy. Founded in 2002, the consortium is comprised of a small dedicated staff and a number of research partners and associates.
Created in the 1960's by Dr. Douglas Engelbart and his imaginative team at Stanford Research Labs (SRI), Augment is one of the most groundbreaking and important historical artifacts of the software industry. Many of today's desktop and network computing innovations can be traced back to the original Augment system.
Today, the OpenAugment Consortium is taking steps to ensure that future generations will have access to the Augment legacy through this open source initiative. Please explore the rest of this site to find out more about Augment, the OpenAugment Consortium and how you can play a part in preserving this vital piece of computing history.
Today I am listening to one of the local "classic rock" stations. The DJ announces it's "Two for Tuesday". He also announces "We're in the middle of a 25 song classic song salute."
So does that mean for the 13th artist "two-fer" they're gonna play a classic and then a flop?
I'm just thinkin'.
