CORBA Redux

Roger Sessions is a bit of a character. Witness his back-and-forth with Terry Coatta in ACM Queue around CORBA and Web Services. Sessions continues to point out that CORBA worked when CORBA was on both ends of the wire. Well, what else would you expect? Does HTTP work when HTTP is not on both ends? For some reason Sessions seems to believe that WS-* does not require WS-* on both ends.

For years now Sessions has promoted DCOM and now he promotes WS-*. A continuing theme of these promotions is that CORBA has failed. Certainly DCOM failed worse than CORBA. Moreover, as Coatta points out...

It looks to me like CORBA is more of a success than Web services.

The CORBA community learned many lessons and would have been even more of a success had that organization incorporated the web sooner and more naturally. WS-* usurped CORBA on the premise that the result would be simpler and better, yet years later both claims remain suspect.

Later in the exchange Sessions says something incredible. Upon admitting the WS-* specs are *more* complex than CORBA's, Sessions suggests that is OK...

I agree that the Web services standards are harder to understand than most of the CORBA specifications, but there’s one fundamental difference between these specifications and the CORBA ones. The CORBA specifications had to be understood by developers. The Web services standards don’t. Nobody needs to understand the Web services standards except for Microsoft and IBM because these standards are about how Microsoft and IBM are going to talk together, not about how the developer is going to do anything... These standards have no relevance to Joe or Jane Developer, none whatsoever.

This is ironic since a few minutes previously Sessions complained that these vendors are in danger of making WS-* too transparent...

In some sense, the transparent ability to make something a Web service is not really a good thing, because making an effective Web service requires a much more in-depth understanding of what it means to be a Web service.

Coatta catches this apparent contradiction...

It sounds like what you’re saying is that the tools that automatically supply Web services interfaces are, in fact, absolutely necessary because they’re that insulation between the developers and the underlying protocols. At the same time, they’re the downfall that’s making it possible to generate poorly architected systems. Two-edged sword?

Sessions has little to defend himself with other than to suggest that although these tools don't prevent bad architectures, just think how bad the architectures would be without those tools.

I'd give Coatta the victory in this debate. Too much confusion from Sessions who has not made up his mind whether tools, protocols, or APIs are good or bad...

The big difference between Web services and CORBA is that the Web services people said right from the beginning: there is no API.

So there is no API, because those are bad. But the protocols are damn near impossible to understand. But that is good, because we only need two vendors and they can provide tools. Well, as long as they don't provide APIs, 'cause that would be bad.

The only thing more confusing than the mess of WS-* specs is the explanation Sessions is trying to proffer.

Spiral Staircase: Going Up or Down?

Jon Udell asks a great question...

In the realm of service-oriented design and business-process modeling, what are the modern counterparts to Lisp and Smalltalk?

First, who says Lisp and Smalltalk are not "modern"?

Second, I don't know the answer. Neither Lisp nor Smalltalk offer more than any other tools for these purposes. I don't think we have much in these spaces yet.

An argument could be made that for service-oriented design the counterpart seems to be HTTP. Whether or not HTTP is the best we can do is moot. Lisp and Smalltalk were allowed to evolve in elite laboratories for a decade or more before widespread adoption. HTTP is simple with demonstrated success, but I'm not sure a successor will emerge from an MIT or a PARC anytime soon.

As for process modeling... we are in worse shape. I developed electronic design and manufacturing software (e-CAD, CAM) for many years, 1983-1993. This work included developing schematic editors as well as software that consumed schematic data. In those days there were few standards for this kind of software, interchange formats, or protocols.

I see several parallels to todays BPM software. Standards like BPEL are a start, but there is a long way to go on the front and back ends for these systems.

Back to services... I think we have a long way to go here as well. Most services I am aware of (whether they are REST or WS-*) are built on languages that emphasize the "inward view" of the system (e.g. the arrangement of code and data within the process) rather than the "outward view" (e.g. the service interface and contract). Sure there are "declarative metadata" schemes in various languages for denoting some function should be a web service, etc. But these schemes are bolted on to previous generation languages. Accessing semi-formal data from multiple sources and "mashing" these together appear to be another capability in demand.

What other capabilities should such a language provide? What about features for security? Availability? Distribution?

Comments are gone

I have republished the blog without comments. There will be no more comments until I can prevent the spam attacks. I have been all but unaffected until now. The losers lose for us all.

Feel free to send email directly to me in lieu of comments on any topic.

Threads, Processes (and Shared Memory)

James Robertson quotes from several interesting pieces on threads, processes, and programming models. I am squarely in the multi-process camp too. I remember my absolute shock about a decade ago when I learned Java (at that time aimed at being a simple web programming language) had a shared-memory with monitors concurrency model.

The key phrase there is "shared-memory". Threads in and of themselves are not the problem. The shared-memory model is the real problem.

With a shared-nothing model then threads take on much more of a "process" feel. Languages like Erlang and Termite implement lightweight shared-nothing processes above the level of the OS. The benefits of sharing lightweight processes within a single address space provide a "best of both worlds" model. Sharing can take place under the abstraction of the language... the runtime benefits of sharing but the developer-time benefits of isolation. Whether an associated process is local, or in another OS process, or on another node, is irrelevant in many respects. Performance, reliability, etc. are still concerns so the distribution problem is not completely abstracted away.

Smalltalk Leading the Way

David Buck writes about an enticing upcoming meeting of the Ottawa Smalltalk User Group...

Smalltalk and Smalltalk developers have led the way to the modern techniques and practices that [David] teaches in Simberon's courses... even now, the future of software development is being led by Smalltalk whether or not the rest of the world cares to notice.

Happy Goldfish in a Bowl

Having dabbled on the edge of AI for a number of years, I enjoy the technology as well as the philosophy that surrounds the subject. Jon Udell writes of the so-called Singularity...

That's us: just goldfish to the post-human super-intelligences... True machine intelligence was what the advocates of strong AI wanted to hear about, not the amplification of human intelligence by networked computing. The problem, of course, is that we've always lacked the theoretical foundation on which to build machine intelligence. Ray Kurzweil thinks that doesn't matter, because in a decade or two we'll be able to scan brain activity with sufficient fidelity to port it by sheer brute force, without explicitly modeling the algorithms.

Now's time for this goldfish (me) to refresh himself with a healthy dose of Terry Winograd and Fernando Flores. I don't consider myself religious in the least. However I think that neither "intelligence" nor "emotions" are in any way mechanical (i.e. transferable to a machine). I do think they are *biological abstractions*. They are the names we give to our interpretation of biological (and so, chemical, and so, physical) processes.

Back to Jon on the current understanding of human vision...

We are, however, starting to sort out the higher-level architecture of these cortical columns. And it's fascinating. At each layer, signals propagate up the stack, but there's also a return path for feedback. Focusing on the structure that's connected directly to the 14x14 retinal patch, Olshausen pointed out that the amount of data fed to that structure by the retina, and passed up the column to the next layer, is dwarfed by the amount of feedback coming down from that next layer. In other words, your primary visual processor is receiving the vast majority of its input from the brain, not from the world.

We can manipulate biological and psychological processes. We can mimic them mechacinally to increasing degrees. But we cannot "make them" out of parts and we cannot "tansfer" them to such a machine. What would that mean? The simulation of the hurricane is not and never will be the hurricane even if the simulation actually destroys the city. Something destroys the city, but it is not a hurricane.

A machine that has some representation of my "brain" may continue to develop a further simulation of what my brain would be like had it undergone similar stimula. But in no way is that machine now "my brain" and in no way does that machine "feel" things in the way my "real brain" feels things. Those feelings are interpretations of abstractions of biological processes. The machine is merely a simulation of such things. If you care about me and then observe further simulations of such a machine you may further interpret your observations to be "happy" or "sad" and you may even interpret that machine to be "happy" or "sad". But that machine is in fact not happy or sad in any biological or psychological sense.

Let's face it, even my dog "loves" me because I feed it, and when it comes down to it my kids do too. We are abstract interpreters of biological processes. One interpretation of that may be "loneliness" but so? Here is where I note that my dog gets as excited to go out and pee as it does to see me come home from a week on the road. Fortunately my kids have a finer scale of excitement.

Back to Jon for more about augmentation rather than "strong" AI...

I had the rare privilege of meeting Doug Engelbart. I'd listened to his talk at the 2004 version of this conference, by way of ITConversations.com, and was deeply inspired by it. I knew he'd invented the mouse, and had helped bring GUIs and hypertext into the world, but I didn't fully appreciate the vision behind all that: networked collaboration as our first, last, and perhaps only line of defense against the perils that threaten our survival. While we're waiting around for the singularity, learning how to collaborate at planetary scale -- as Doug Engelbart saw long ago, and as I believe we are now starting to get the hang of -- seems like a really good idea.

Seems like a really good idea. "Strong" AI is fascinating, but "augmentation" is useful.

Streamlined Concurrency Modeling

I like this book Blaine refers to. It's been sitting on my shelf for a couple of years where I've picked it up and dusted off a few pages here and there. Recently I have been following it a bit in practicing *concurrent* programming as opposed to object programming per se.

Concurrent processes can be seen as "active objects". Not every object in your system should be concurrent (not even in a concurrent programming language like Oz, Erlang, or Gambit Scheme). But the significant ones almost certainly should.

An active object (concurrent process) in these systems are like smallish databases and application-specific protocols for accessing them. Each process has state and essentially implements a loop of selecting the next most important message, interpreting it, and updating its state (its little possibly-persistent "database"). These message-passing protocols are not unlike the protocols of messages sent to (sequential) objects.

More later. If you have any favorite references for concurrent programming leave a comment.

Nintendo Revolution

The long-rumored controller for the Nintendo Revolution has been revealed. What a winner.

My understanding is Nintendo was the early innovator of the common features of current controllers. This is another revolutionary advance from the looks of the video from the Tokyo Game Show.

I have been telling my kids for years that once a controller along these lines gets us away from the unnatural button combinations I'll be able to kick their butts. They have a physical memory for modern controllers I have never invested enough time in to become competent. That is why I am competitive with them on games like Mario Kart Double Dash (simple controls), but not on most games.

Now we shall soon see if my words will hold up. This controller looks to make all sorts of actions more directly translatable into the game.

I don't care what else is in the Revolution. I am not a big gamer at all but I cannot wait to try out this controller. Cell wha? 360 wha? Ho hum. I could become more of a gamer with this controller. My 13 year old showed me the video last night. At first I thought, what, the controller is a TV remote?

But watch the video of it in action. I hope they have the virtual drum set ready to go in March!

Finally Integrated Query

Looks like a popular production language design finally will provide a query capability that disregards the kind of data (persistent or not, objects or not, XML or not) being queried. Visual Basic just became somewhat appealing for this and some other new features. I still have reasons not to use it, but this is an appealing step that will benefit many developers for some time to come.

Kudos to Visual Basic. Does C# have *all* these same features? I've not read all the PDC news yet.

Gambit Scheme 4.0 beta 15

Gambit Scheme 4.0 beta 15 is available. Changes include the incorporation of some Termite capabilities, in particular each thread has a mailbox for receiving asynchronous messages.

Beware Dichotomies

Paul Graham's latest essay is making the rounds. My initial reaction reflects my general approach to socio-political issues: beware dichotomies. Really, beware those who would present any complex issue as a dichotomy. Paul's opening paragraph has to be the worst in all his essays unless he was *intending* to present to us a straw man.

By the end of the essay though he makes at least one excellent point: transparency matters. Yes, wealth is power and I think Paul fails to recognize how closely wealth and power are related, let alone to begin recognizing the good and bad of that.

If global capitalism is going to work (I currently give it a mixed review but that's another story) then we need to remember that the theory itself is founded on "perfect knowledge". The closest things we have to perfect knowledge are democracy and transparency.

Why (not) Smalltalk?

A coincidence that on Sam Ruby's blog and on the Extreme Programming Yahoo Group on the same day there are conversations about using Smalltalk. Both conversations are along the lines of...

OK, Smalltalk is very good. So why use a language influenced by Smalltalk? Why not use Smalltalk itself?

Sam's quote is so good...

Reinventing Smalltalk One Decade at a Time

Collapse

What happened to New Orleans is terrible. But as James Robertson points out, it was not unanticipated.

The situation reminds me of our increasing understanding of earthquakes where I live in the Pacific Northwest. A similar hell could break out at any time here.

Jared Diamond's book "Collapse" addresses this recurring theme. A societal collapse is often triggered by an environmental collapse. These days the signs of a coming disaster are well known if not widely acknowledged, let alone acted upon effectively.

What Google Gets

Steve Gillmor has a great characterization of where Google could be going. Rather than trying to build the platform for everybody, Google seems to want everybody to build the platform for them or rather, with them. Google could be engineering something at the scale of the Internet, not just producing a suite of somewhat related products. If others continue to join in, the competition could be dizzying. Steve called it "iterative competitive development", "overlapping interoperability" rather than "lock-in" or "lock-out".

Anyone not taking this kind of approach probably is locking themselves out.

Threading Eras

James Robertson points out the difference between "native" OS threads and threads implemented in the language runtime. Some people (as quoted) see mapping language-level threads to OS threads as a good thing.

In part this may come from Java's first implementation of threads (aka "green" threads, a term Jim also applies to VW Smalltalk's threads). These had their share of implementation problems early on and so before long the Java community seemed to gravitate toward an anti-green-thread attitude at the conceptual level. Only now for example is BEA's JRocket JVM *experimenting* with a high-performance non-native thread implementation they call "thin threads" (wisely avoiding the "green" label).

As VW Smalltalk, Gambit and PLT Scheme, Erlang, and the Oz language demonstrate, highly concurrent programming requires much lighter-weight mechanisms than OS threads. (For the typical OS.)

Apparently most Common Lisp systems have heavy thread implementations and so the ErLisp implementation may not scale up as well as these other systems either.

A File System For (or To) the Rest of Us

Update 2: comments on WinFS capabilities...

Across the network you could still use it as a WinFS if you have WinFS installed. If you don't, it's just a file system, so you're not locked to it. It might be better just to use a common, standard, protocol; the idea that it's appropriate to degenerate to file system behavior is just retro

Update 1: Michael Lucas-Smith has another useful take on WinFS. I am not as thrilled by the synchronizing capabilities in these local pseudo-databases as he seems to be. I have a different interpretation of the Network being the Computer. Michael suggests a Topic Maps-like capability on top of databases or files or whatever might be more useful than WinFS. I agree with this, and I agree having to rewrite apps is a problem. Those seem like two different issues though that each need to be addressed.

I do agree with one vision of WinFS... I think we need easier structuring as well as semi-structuring mechanisms. A relational database is a structuring mechanism. A topic map is a "semi-structuring" mechanism. Big old-fashioned databases are good at structuring, it's just they suck at ease of use and ease of operations.

Michael points out some capabilities of SQL Server (and Oracle). For example they *can* act as file systems. But who uses them as file systems? Which goes more to the point: These more mature databases are too cumbersome. However file systems are too limited. WinFS is trying to hit somewhere in between. I think they are aiming at the wrong target.

Hopefully Microsoft is heading toward better support for unstructured data. But if WinFS is the best they can do for *structured* data... they should try again. A "local" filesystem/database with some proprietary synchronization capabilities is just not what I think we need. If we're going to rewrite systems for the formal aspects of structuring data then we can do better than a system which appears to be something less than a Lotus Notes database at best.

The bottom line for me is: whatever WinFS *is*, well, it should be *that* for the network. WinFS should not be something for me if it happens to be running on my specific box, something else for you if it happens to be running on some other specific box.

End Update 1

A telling quote in the Channel 9 piece on WinFS...

"WinFS -- to the rest of the world it's important that it looks like a file system"

A better philosophy would be this:

To the rest of the world it is important that it looks like WinFS.

But apparently the WinFS team has not entered the age of the network is the computer. I think that is what is important to "the rest of the world." Why degrade capabilities over the network?

The WinFS team continues to be stuck in outdated thinking.

Piracy

A graph showing the inverse relationship between global temperature and pirates. Actually I think there may be as many pirates as ever. So this *could* very well turn out to be bad science.

Trusted Computing and Digital Rights Management

Someone once said, "Follow the money." The aphorism is broadly applicable.

Note that the opinions expressed here are my own. In the interest of full disclosure, I currently am paid by Intel Corporation to do something akin to real work and I own Intel stock, but my work for them has nothing to do with Trusted Computing, nor do I have any privileged insights into that technology.

So here's my thought: I find irony that the Internet continues to be victimized through its own orifices, especially those on the common endpoints, while an appropriate solution, Trusted Computing, is getting a bad rap because some media companies want to use it to prop up their derelict business model (see Digital Rights Management (DRM)).

The digital rights problem seems to me to be a social problem in the market, not a technology problem. I think by associating Trusted Computing too closely with DRM. Tim Bray writes...

OK, if there’s ever a place where DRM is appropriate, it had better be open and non-monopolistic and all that.

And this is exactly right... the technology can be used broadly to support capability-based security down to the hardware. All software can be made more secure if this problem can be addressed effectively. The media companies are just a mountain in the road toward safer computing generally. We need market solutions to solve that problem, but the technology should be considered as a potential solution to the fact that insecure office and back office software are still exposing our orifices on the net to whomever wishes to pay an unwanted visit.

Trusted computing *and* greasemonkey might make a terrific combination. (With a fair bit of reengingeering unfortunately.)

Cairo looks cool

A little reminder to myself to try cairo (lower case) 1.0, cross-platform structured 2d graphics.

Oz Fest

Hop, skip, and jumping around... I'm taking another look at Oz, a "multiparadigm" language I took a brief look at a few years ago. Along with the book "Concepts, Techniques, and Models of Computer Programming" my first look was brief and did not I did not appreciate everything about them.

I was originally put off by the shear number of capabilities in the language and presented in the book. On the other hand those capabilities fit together very well now that I am actually working through them.

OK, so the only real oddity is this: unary minus is represented as a tilde. And so...
~10
Should not read as "about ten" but rather "negative ten". This is the same as
0 - 10
using the Oz binary substraction operator, but -10 is invalid in Oz. I guess if that's the oddist thing...

WikiWYG

WYSIWYG in a Wiki. Nice feature. Horrible acronym.

It's a Wiki with better in-line editing.

P2P

And by P2P I mean Point to Point. From Loosely Coupled, appropriately enough...

The deeply ingrained point-to-point mindset of mainstream computer systems design is hampering recognition of some of the most basic concepts required for successful deployment.

Google Map of Site Visitors

(via the lispmeister himself)

My google map of visitors.

Google Talk and Jabber

Update, google sez:

We want to make IM as open as the web or email...

I think that the ultimate destination is to come up with a system that is as distributed and decentralized as SMTP/email while not falling prey to the spam problems that SMTP has. We are going to test those waters first off by starting federation with a few partners and then moving on from there.

End Update

More advances into messaging, voice, and other desk-side goodies from Google...

Independent journalist Om Malik on his blog at http://gigaom.com/ pointed to technical clues that suggest Google is preparing to run an instant messaging service based on an open-source system known as Jabber. Jabber technology would allow Google instant message users to connect with established IM systems that also work with Jabber, including America Online's ICQ and Apple Computer Inc.'s iChat, Malik said.

Multi-multi-core

The future of concurrent computing...

Come 2010, expect to see chips containing ten or more processing cores, he added.
-Paul Otellini at the Intel Developer Forum

The key to building future systems more easily is in languages for making concurrent programming as easy as object-oriented programming has made sequential programming. Objects (and higher-order functions, etc.) make the organization of names and sequential statements more manageable. Good concurrency models make the organization of space and time more manageable.

A programming language's concurrency model will have to support programmers conceptualizing tens and hundreds of thousands of processes the way languages today support programmers conceptualizing object models of tens and hundreds of thousands of objects.

Polar Opposite

Have you ever been dumbstruck by a polar opposite opinion that is perfectly valid just nothing you could image yourself.

Then Apple fell into a huge hole. It started with "Hypercard". It was a ridiculous way to build programs. I could never understand it.

Hypercard is about the most fun I've ever had with a computer.

Cheap Gas -- more fun with google maps

(via Mark Baker)

... the web wins again. Find cheap gas.

Portland has typically been more expensive than non-left-coast locations in the US. At least Portland does not seem to be increasing as quickly as some other locations.

SAP Trex Search Engine and Python

Interesting comment from Andrew Barnard...

SAP uses Python as an integral part of the TREX product and has done so for many years.

Perhaps Shai is not aware of the extent to which open source products are used by SAP?

Oh, that OODB

Guess what? Transparent persistence has sex appeal but gotchas. (de hÓra and Thornhill punch) Look before you leap. Things are not always what they start out to be.

Emacs of the Web

Bill de hÓra contributes to the "one click subscription" discussion, or what he dubbed "clicksub"...

I don't use browsers much anymore and will be using them even less next year. Aggregators are so much better than browsers for following content. Really, if you have to read stuff on the web and are using a browser for that, you should try an aggregator. And then, what's the browser good for?...

To be honest, next year's browsers need to be aggregators, else I don't see the point in using them...

Instead this would be great: at some point weblogs flip over and the HTML website bits will become secondary fluff to the XML content, like how PDFs are secondary web fluff to HTML today. The frontpage would be the feed, the archives would be Atom entries...

Honestly, permalinking to a html file is starting to look more and more like a bug. Why not point to the XML entries?

I was going to blah blah about some analogies with Emacs. Hard-core emacs users find themselves snickering about artificial boundaries around "applications" -- there is very little concept in the world of Emacs that "this thing is a word processor" but "that thing is an email reader" and "some other thing is a directory explorer". And the list goes on for outliners, class browsers, PIMs, etc.

The underlying problem may be there is no (not yet) Emacs of the Web. But Bill what I get from Bill's post is my Emacs perspective is mostly a "front-end perspective". There is a whole back end perspective on the future of feeds, pages, formats that is in its infancy.

Emacs was born as a set of flexible front-end parts in the 1970's. Even in the world of objects and MVC, a significant number of programmers were just starting to grasp the same concepts in the late 1980's and early 1990's. By and large, looking at our software landscape, we still have not grasped the concept. In fact, the browser may be the closest thing we have to this on a widespread basis!

Not only does Bill show this is not seriously the case, by now we really should have moved on to the back end of resources, formats, and hyperlinks. The head spins. We have a lot of catching up to do.

When to create syntax in Lisp?

From the gambit email list, I respond to this question about writing macros...

In your opinion, is it appropriate to use a macro to abstract away repetitive boiler-plate code? Or is this better done in a procedure?

This is almost always a procedural abstraction rather than syntax, especially for beginners with Lisp... better to spend a lot of time with just procedural abstraction, higher-order functions, etc.

Syntactical abstraction I use for controlling the order of evaluation and sometimes to put a pretty syntax around use of lambda.

As an example an old Lisp control structure is called PROG1. This structure takes a sequence of statements, evaluates each in order, and returns the result of the first statement after the last has been evaluated. This is can be expressed as a Gambit macro, but I'll call it begin1 to be more like Scheme's begin than the old Lisp's progn.

? (define-macro (begin1 first-statement . remaining-statements)
    (let ((result-var (gensym 'first-result)))
      `(let ((,result-var ,first-statement))
         , at remaining-statements
         ,result-var)))
? (begin1 1 2 3)
1
> (begin 1 2 3)
3
? (define result-var 5)
? (begin 1 2 result-var)
5
? (begin result-var 1 2 3)
3
? (begin1 result-var 1 2 3)
5
? (begin1 0 (display result-var) (newline) 1 2 3)
5
0

The begin1 is an example of control abstraction.

An example of the latter use of pretty syntax... consider a scenario where you are using a resource and you want some "before" and "after" actions. The base level way to implement this is with higher-order procedures. But who wants to write (lambda () ...) all the time? So on top of this build some pretty syntax. [Note that a better lambda notation like Smalltalk's block syntax would reduce the need for these situations. (pdf)] For example...

(define (call-when-ready procedure)
  (wait-until-ready time-out)
  (if (not (ready?))
      (call-when-ready procedure)))

Use it like this...

(call-when-ready 
  (lambda () 
    (display "I am glad this is finally ready!")
    (newline)
    (do-something)))

This is fine when someone else is generating the code for you. Normally you might want to abstract the procedure as a sequence of statements...

(when-ready
  (display "I am glad this is finally ready!")
  (newline)
  (do-something))

And so when-ready is defined as a macro that calls call-when-ready...

(define-macro (when-ready . body)
  `(call-when-ready
     (lambda ()
       ,@body)))

Will Farr added a neat example in the same thread...

Making little sub-languages for specialized processing e.g.

(with-vectors (v1 v2 v3) (v1 <- (+ v2 v3)))

for summing up the vectors v2 and v3 and storing it in v1. (I'm not going to put this macro up because it's long---the code is buried in this post: http://wmfarr.blogspot.com/2005/06/bigloo-macros-and-repl.html .)

[This] involves changing the evaluation rules for a piece of code (the vector assignment is evaluated once for each index with the corresponding variables bound to elements of a vector).Procedures would not work for either of them; you have to have a macro.

Because

Because the world is round...

Identities, Associations, and Behaviors

Doc Searls has the lead article in the September Linux Journal on "Identity". This is yet another topic I have barely understood. My interest is growing though with the concept of "user centric identity".

The title of Searl's article is "Independent Identity" which points out an irony of sorts that's been on my mind. My impression is that this is not about "identity" at all. Rather it is about "association".

What use is an independent identity? I have to associate my identity with some other body's identity to accomplish anything. The crux of the "user centric identity" effort is how to limit the ramifications of that association.

The other thought that's been brewing is the relationship between capabilities and identity. We know our current approach to permissions is not sufficient to limit or even audit the results of association. On the other hand if I can reliably limit the available behaviors of my associates, and they mine, then we can mutually benefit from our association.

Identity without behavior does not lead to associations. Since we are after beneficial associations, I'm assuming we need to focus on how "identity management" ultimately translates into appropriate behaviors and reliably excludes inappropriate behaviors. A capability system requires identity management to communicate with the outside word. I also assume an identity management system requires capabilities or something equally secure to ultimately implement trustworthy associations.

I'm looking forward to Phil Windley's new book on Digital Identity to get a better handle on some of these ideas.

DZ

and now, daily zen...

By sitting alone all day long
I clear my mind of a thousand thoughts.
To speak of this is beyond our words;
Only by sitting under the quiet forest
Can we ever understand.

- Fa Yen (885-958)

uuid

Termite currently has a dependency on libuuid to generate universally unique identifiers. Since there is no need for the result to conform to the uuid_t data type, just that the result is unique across space and time, I wrote a uuid generator in Scheme which will make running Termite easier on more platforms. I loosely followed the pattern for generating primary keys in EJB Design Patterns which does not require a singleton or a database, etc. i.e. multiple instances of this uuid maker can exist in the same address space or in different address spaces, and on different hosts. I had fun replacing the absolutely horrible C code from libuuid with short, readable, Scheme.

> (load "my-uuid.scm")
"/home/pdlogan/dev/termite/my-uuid.scm"
> (define make-uuid (make-uuid-maker))
> (make-uuid)
"1A10E03B-4FF3486B-00000057-F7CA93A2"

The result is a 128-bit unsigned integer but the only requirement is that it is a unique Scheme object across space and time (within a reasonable amount of certainty). The code is actually following the convention for uuid's, i.e. display each 32-bit part in hex separated by dashes.

Each call to make-uuid-maker returns a new closure around an "address part" and an "object part". Every uuid this closure makes will be unique to its IP address and unique to the internal id of the object in the specific Scheme runtime. (Note: the original uuid generators use the network card MAC address but the IP address is easier to get and just as good for this purpose.)

Each call to one of these closures combines its address part and object part to a "time part" and a "random part". The time part is roughly the number of milliseconds since January 1, 1970 mod (2^32)-1. The random part is a random 32-bit unsigned integer. So within the closure's IP address and randomly allocated object, each resulting uuid is also made unique to the millisecond and a random number *within* the millisecond.

(define (make-uuid-maker)
  (let ((address-part (or (hex-encode-ip-address)
     (hex-encode-random-integer)))
 (object-id-part (hex-encode-random-object-id)))
    (lambda ()
      (let ((time-part  (hex-encode-current-milliseconds))
     (random-part (hex-encode-random-integer)))
 (string-append time-part "-" address-part "-" object-id-part "-" random-part)))))

The IP address is the host's internet address if it has one, or an intranet address, otherwise the address part becomes just another 32-bit random integer.

(define (hex-encode-ip-address)
  (let* ((address (or (get-internet-address)
        (get-intranet-address))))
    (if address
 (lengthen-with-leading-zeros
  (number->string (string->number
     (let ((result ""))
       (for-each
                                (lambda (n)
       (set! result (string-append result (number->string n))))
    (u8vector->list address))
       result))
    16))
 #f)))

The object id closed within a uuid maker is also random. If a closure is always created at a specific point, e.g. in initialization, then this object runs the risk of having the same id each time. Instead a random number of objects (not more than 100) are created before the one captured in the closure.

(define (hex-encode-random-object-id)
  (let loop ((n (random-integer 100)))
    (let ((id (object->serial-number (cons 1 2))))
      (if (= n 0)
   (lengthen-with-leading-zeros (number->string id 16))
   (loop (- n 1))))))

Well that was fun. If you see any serious flaws let me know. There are some Gambit-specific dependencies here but nothing too difficult to replace. The formatting's really bad, but I am off to the beach for the day so later.

Left Field

This will take some digesting to grok...

"If the Java Content Repository (JCR) API expert group's vision bears out, in five or ten years' time we will all program to repositories, not databases, according to David Nuescheler, CTO of Day Software [4], and JSR 170 spec lead. Repositories are an outgrowth of many years of data management research, and are best understood as fancy object stores especially suited to today's applications."

John Dougan comments...

My goodness, that data model reminds me of RDF. Is there a database/datamodel equivalent to Greenspun's 10th Law?

Interesting comparison to think about. For the sake of argument more than having made any real deep theory, I have previously wondered aloud whether there are a small number of common data persistence patterns.

AJAX lessons

Philippe Bossut's notes from the OSCON 2005 tutorial on Learning AJAX...

Most interesting stuff I learnt
Size of the data you can send and cache in a typical XMLHTTPRequest: 4K (small!). Best data type to return: JavaScript instead of XML.

(Alex Russell's PDF)

json-py update

Some fixes to json-py are on sourceforge. Also included is Jim Washington's minjson.py which is faster but not as compliant (as per the spec).

json.py is intended to be a straightforward implementation that can be easily duplicated in other languages.

The Right to (Apply for) Work?

Do American programmers have the right to work in America?

The answer may surprise you. Or not, in our new plutocracy.

Update: Someone commented...

US Constitution does not garantee employment opportunity for any specific type of job.

And of course this comment is correct. So I clarified the title of this entry. See the parenthesis.

This comment really misses the point of the referenced article. The visas are intended to bring in temporary skills from outside the US where those skills are in short supply.

If US citizens are unable to even *apply* for the more than 50,000 open positions, how can anyone tell that these positions cannot be filled by Americans? That is the point... the powers that be are circumventing the purpose of the visas (i.e. fill a temporary labor shortage) in order to gain an advantage over American workers (i.e. bring in more labor and lower the demand for salaries) that is unintended by the visa laws.

Is that more clearly stated? This is not about a right to work. It is about a law and the circumvention of that law for anti-competitive purposes at a time when many Americans are losing careers and only replacing them with lower paying jobs. That may well be a trend of the emerging global economy, but that does not excuse the practices by the US department of anti-labor in these 50,000 plus positions. There is no right to work, but neither is there a right to exclude Americans from applying for jobs in America, for crying out loud. Get real.

Things That Make Me Go Hmmm

Some things might make *you* go hmmm. However there are other things that make *me* go hmmm.

While the APP is 'just a' publishing technology and Atom is 'just a' syndication technology, there are five reasons to that microprotocols - namespaced module extensions that inform and affect application behaviour - will appear as an alternative to WS and SOAP based technologies by targeting enterprise computing concerns like reliable messaging and tracking.

Hmmm.

Crystal Ball of Mud

Via the Register...

EDC believes PHP's recent glorious past is over, as customers spend money on "more important" technologies to build mission critical systems and vendors like Microsoft and Sun Microsystems make more of a concerted marketing push around alternatives such as ASP.NET and JavaServer Pages (JSP).

Really?

Peter Yard says (yes, via Phil Windley)...

Things have -- gotten simpler.

Really?

Liberation Theology

Again Phil Windley, this time relaying DHH on Rails, but the philosophy is generally applicable...

When you insist on flexibility over everything else, you sacrifice velocity and agility. Constraints are liberating.

Arbitrarily Complex Messages

SOAP vs. HTTP... Phil Windley blogs about Randy Ray's talk at OSCON 2005. Ray suggests an example where SOAP is better than HTTP. Phil's paraphrasing...

The CalculateRoute API allows not just a start and end point, but also an arbitrary number of waypoints along the way (to calculate the route for an entire trip).

Since this is a constant resource—the route won’t change (much)—this should be a GET request with a URL. Designing such a GET request is difficult. There’s no real standard for creating a REST protocol. There’s no WSDL.

But we can get WSDL and SOAP to fall down flat as well. This route calculator takes a fairly simple list of values. A more complex calculator could take fuzzy values... for example a preference rather than a requirement to travel through a particular location, or a preference to travel through a particular location if the total trip time is not more than N time units, or...

The example can easily exceed the ease of expressing in WSDL. Then what's the value of WSDL? WSDL maps fairly well onto currently popular imperative languages, not very well onto constraint logic programming languages or deductive logic languages, or...

GET in HTTP seems to me similar to an object reference. Sometimes a query is needed to get the reference in the first place. But once I have it, I can "dereference" it over again.

I suppose POST is the means to do the query, and POST can take arbitrary data just like a parameter in a WSDL definition.

So I guess I don't get the argument. Certainly WSDL is not the end of the story except for some small set of convenient API's similar to those you'd write in Java, C#, or C++.

HPC

Matt Stansberry writes...

What is holding High Performance Computing back?

With the hardware becoming commoditized, why aren't more companies using HPC? According to a report from IDC and the Council on Competitiveness, minimal support from software vendors and a lack of training are the culprits...

Writing code to take advantage of the new clusters means scrapping the code written for the scale up models of the past, an expensive proposition.

Why I Live in Portland

Ted Leung writes about Portland...

Being at the convention center is helping me to discover more about Portland. The free ride zone for the Max train is a thing of beauty. I had thought Seattle's bus free ride zone was good, but the Max train beats that all to pieces. Combine that with Portland's short city blocks, and wonderful downtown, and it's all very appealing. I've had lots of conversations (usually on the way to meals) about how nice Portland is.

This is where we are supposed to tell you how much it rains in Portland. That's a tough sell this time of year... typically nothing but blue skies for weeks.

But there is a reason OSCON is not held in Portland in November. 8^)

Why I Live in Oregon

A photo from an OSCON 2005 attendee shows why I live in Oregon. This spot is about an hour from my house. It doesn't get any better than this for me. If you don't like the rare 90F days in the summer, just drive over the Coastal Range an hour and you are likely to get 60F because the hot valley is sucking all the moisture in from the Pacific. Camping on the beach in August often means you'll be wearing sweatshirts and jackets in the afternoon.

(And here are all the OSCON 2005 photos.)

Whither Object Databases

Jonathan Robie, in an interview with Jon Udell, captures the reason for failure of the object database market better than any explanation I've seen...

JR: OQL is a nice language. The grammar of XQuery has benefitted a lot from it, and some of the implementation has too. Of course, it wasn't commercially relevant for the object database vendors to implement OQL in any kind of complete way.

JU: Because?

JR: Every object database had a different market, and a different model, and people weren't looking for interoperability between ObjectStore and POET, because why would you use them for the same thing?

Gems: Servers, Blogging, etc.

Phil Windley reportedly paraphrasing Paul Graham at OSCON 2005...

Someone who proposes to run Windows on servers ought to be prepared to explain what they know about servers that Google and Yahoo don't know...

The NYT front page is a list of people who write for the NYTs. Del.icio.us is a list of people who are interesting. You can see them side-by-side. You can see how little overlap there is...

Start-up environments are more like home work environments. This is probably the most productive the company is ever going to be...

Meetings count for work, just like programming, but they're so much easier.

Aw, just go read it. There are too many gems to quote.

Adding Capabilities

Chris Double writes in a comment about Factor and his concurrency model...

I'm also keen to look into capabilities and how support for that could be added. But I'm completely unknowledgable in that area at the moment.

I intend to look into this with Termite and hopefully discuss this with Guillaume and I hope others.

The basic idea is to give each process its own set of known capabilities and aquire new capabilities from other processes (some coming from the "outside" world). A capability would be the ability to send a message to another process and some fundamental actions like spawning a new process, file I/O, etc. Joe Armstrong's work on unifying these actions as all being message sends would help with the design.

This implementation would require capabilities (e.g. process ID's and perhaps node ID's) to be unguessable and unforgeable. Rather a Pet Naming scheme would make capabilities more usable for developers.

Similarly connections to the outside world, e.g. the Internet, would apply the concept to URL's and so on.

Update: This reminds Chris of Plan 9. Just so... Plan 9 I recall has the same ability to map a tree of names (i.e. file system) onto a set of capabilities (i.e. the actual files, drivers, etc.) such that any given user's tree of names will refer to potentially *different* objects, based on the capabilities that user has.

In a Nutshell

As relayed by Blaine Buxton...

"Finally, the days where a novice programmer can know all of a language are gone, at least for the languages in widespread industrial use. Few people know "all of C" or "all of Java" either and none of those are novices. It follows that nobody should have to apologize for the fact that novices do not know all of C++. What you must do - in any language - is to pick a subset, get working writing code, and gradually learn more of the language, its libraries, and its tools."
-Bjarne Stroustrup from "Why is C++ So Big?"

"If a system is to serve the creative spirit, it must be entirely comprehensible to a single individual."
-Dan Ingalls from Design Principles Behind Smalltalk

Lists. Really? Can we expect better?

Catching up with things missed while on vacation. Bill hÓra writes...

Technically speaking a list module is so simple, so trivial, that my best guess has been that we developer types just haven't bothered to do it... Socially and commercially however having a unified list format that isn't buried in HTML is going to be insanely valuable. The problem with HTML lists is that you can't get at them, class them, tag them, most importantly, share them...

Whatever happened to microformats? List up to three things:

1. Item 1 here.
2. Item 2 here.
3. Item 3 here.

...it's the XML, stupid.

This is my way of saying I *still* don't get XML. I make no apologies.

For the record, I had the same reaction to OPML. I still don't get that XML either.

Do we need OPML *and* MSFT Simple List Extension? Do we need either? I am unconvinced.

The Problem with Data

Danny Ayers observes...

The problem of data on the Web hasn’t been solved, it’s just been passed along a little.

Tiger and Termite

I installed Tiger this week on my Mac. I had Jaguar and skipped Panther, so this is a big step up... I love it. Dashboard, Spotlight, I have to spend more time with the Mac.

Ugh. Gambit Scheme (and so Termite) just compiles on my Linux box. I expect it not to compile all that well on Cygwin. It does compile but I need to track down things like getting libuuid to work right. Dynamic loading may never work right I suppose.

But I did expect Gambit to compile more easily on MacOSX which is just a Unix. Gambit really likes Linux apparently. The compile went OK, but the tests are breaking in the most unexpect places... like fairly simple interpreter tests.

I am eager to run Termite on Linux, MacOSX, and Windows concurrently and migrate processes around the horn just for kicks.

BTS 2006

This is good news from Don Box on Biztalk Server 2006. The current installation process is desperately painful.

Simple default installation will get more people playing and learning, which is needed to understand the pros and cons of BTS. Let's hope some other usability issues have been similarly addressed. Unless you *like* programming in the lower right hand corner of your screen. 8^)

Concurrency-Oriented Programming Languages

Chris Double is implementing a concurrency model for Factor based on Erlang and Termite. This could catch on.

But hey!

Now I found this interesting. I knew that TBL initially developed on NeXT with Objective-C, but...

HTTP was designed as a distributed realization of the Objective C (originally Smalltalk) message passing infrastructure

...hey!

(via Mark Baker)

Fundamentals of A Security Hole

I hope no one is surprised about the "Greasemonkey Crisis".

Most closed source and open source running applications, middleware, and basic services on the internet or anywhere else are based on a fundamentally flawed concept of security. Greasemonkey is no different; moreover Greasemonkey is especially dangerous sinces its raison de'tre is dynamic customization over the internet.

Things could be different without too much trouble, but the first step is to recognize the real problem and well-known solutions.

Jon followed up with some important questions and implications. And so I should qualify my claim of "without too much trouble".

That should read "without too much *technical* difficulty". The challenging problem I stated above is the that the core problem is so pervasive: in our current systems, but also in our current thinking. A mindshift is needed to recognize the technical problem, realize there are existing technical solutions that are already out of the lab, and that the problem can be tackled one web site and one client application at a time. Not ideal, but much more practical than the ideal.

Some existing solutions that have escaped the labs already: Jon mentioned the E programming language, which if nothing else demonstrates the problem can be addressed on the current Java Virtual Machine. The DARPA Browser illustrates how to use E in a large, real application. The Waterken web application server and the Waterken browser illustrate how to apply the same concept at the level of HTTP and URI's.

The Squeak programming language (Smalltalk) and the Oz programming language are both being extended with E-like capabilities. Objects, virtual machines, web servers are all related concepts (see Mark Baker's recent note and the referenced observation about Smalltalk and HTTP) and all happen to provide a good foundation for capability-based security.

I'll also toss into the mix that concurrency-oriented (pdf) languages like Erlang and Termite are amenable to the same solutions. Capability-based security is just around the corner from our current thinking and our current tools. Capability-based systems can be released onto the internet incrementally, and already have been. Objects, the web, and shared-nothing message passing are all fundamentally doing the same thing... referencing resources and passing around representations of resources that refer to other resources. Just squint a bit to see the similarities and read about capabilities to understand the security aspects of design.

Shaping Systems with Seaside

Mark Watson writes...

if building web apps in Java, PHP, etc., is like carving something out of rock, Seaside is like using clay.

How to Design Large Erlang Systems

From the Erlang User's email list, the question "How do you design large Erlang programs?"

The answers and references from Erlang experts like Ulf Wiger and Joe Armstrong make interesting reading.

Another thread has mre useful design guidance, e.g. on composing state machines from Vance Shipley (and thus).

The Next Postscript

I can count the number of lines of Javascript I have written on, well, 20 hands. The core language makes sense to me, nevertheless: apparently Javascript sucks volumes (volume one and volume two).

My take on Javascript is that it could well be the next Postscript: over time, more of it will be generated than written by hand. Worse is better.

CalDAV

Mark Baker comments...

CalDAV is a red herring. We need calendar-specific operations in HTTP like we need a podcast-specific URI scheme.

This bothered me a fair bit too. Say I want to use WebDAV for authoring schematics of electronic circuits. The CalDAV precendent suggests I would begin a SchemDAV committee.

Makes little sense to me. On the other hand to make calendars or schematics more interoperable I think we should begin agreeing on what the HTTP verbs should mean relative to calendar or schematic resources.

Ideally we would agree what POST means when I send you an event description to your calendar. And that's probably the easiest one. We probably need to do other kinds of resources for and about calendars (and schematics) for searching, comparing, and calculating.

Given the recent ballyhoo of microformats vs. XML -- aren't we still dancing around the verbs? We need to agree on how to handle the verbs to get anywhere deep.

Termite: a Lisp for Distributed Computing

Update via email: Guillaume Germain expects to have a release of Termite in the next few weeks. End Update

Termite is a Lisp for distributed computing. (PDF paper and PDF presentation)

From the presentation...

In short: take Scheme, remove mutations, add isolated processes with mailboxes, add message sending and receiving operations and an addressing mechanism.

The bottom line is Termite is Erlang's distributed concurrency model ported to a dialect of Scheme that has been pared back to something like the sequential aspects of the Erlang language (chapters from Erlang book PDF).

Included in Termite are continuations that can support distributed process migration and macros. Continuations, macros, and closures allow Termite to be more amenable to discovering new abstractions than Erlang.

Termite is from the Gambit team at University of Montreal and runs on Gambit 4.

ATOM or WebDAV: The Rest of the Story?

I do not have a deep understanding of either ATOM or WebDAV but on the surface they seem to overlap in their publishing capabilities. ATOM's does not extend HTTP but WebDAV's does. On the other hand ATOM uses some less well-supported HTTP verbs anyway, so does this point matter?

The ATOM publishing protocol is generating a lot of enthusiasm, even saving us from the WS-xxx. So are these two protocols distinct? When would one be preferred over the other?

What about content-specific issues, like calendars. CalDAV extends WebDAV. Does ATOM have enough not to be extended like this? Should WebDAV be extended like this?

Concurrency Bragging Rights

Wes Moise writes about upcoming advances in concurrency in C# and Java. He sees C# as making the bigger leap into the state of the art.

It’s safe to say that Microsoft will be addressing this issue soon, and probably will be leading the way. As for Sun, Java 5 introduces some concurrency features such as AtomicInteger types, ReentrantLocks, lock-free data structures, but it’s not fundamentally different from concepts that originated in the 60s.

The smart minds at Microsoft Research have been focused on a new concurrency constructs in COmega based on join calculus.

On the other hand many years ago I was using Doug Lea's wonderful util.concurrent package. This has become "standard" now as java.util.concurrent.

The real problem is C# and Java are still languages from the middle of the pack of "the 60s" languages (e.g. Concurrent Pascal). Languages from the best of "the 60s" like Lisp and Smalltalk, have not had to change much and are able to move into new concurrency models with much less baggage.

I am not sure I would hold either C# or Java on a pedestal for the coming paradigm of concurrent programming. Eeek. Termites!

Middling Around the Real Problem

Update: See the comments.

The paper by Meijer and Drayton is making the rounds. As long as Microsoft supports the popular "dynamic" languages I don't care much what other languages they support.

Since the paper is a work in progress and they admit to being provocative, I may as well comment...

First of all I would note that the term "test" does not show up anywhere in the paper. This is a bit of a shock for a paper whose opening sentence is...

Advocates of static typing argue that the advantages of static typing include earlier detection of programming mistakes.

Moving on to a few unsubstantiated claims...

data intensive applications need to deal seamlessly with several degrees of typedness

I did not see a definition of "data intensive" nor did I see evidence of what this "need" is.

not inferring the types of these variables whenever possible is literally throwing the baby with the bath water

Everything has a cost/benefit ratio, which informs the answer to "whenever possible". I could not find a description of this ratio in spite of that being the topic of the paper.

in general programmers want to express more advanced contracts about their code

Yes, but the question is how, and at what cost. Testing, even model checking, could be brought into this discussion. The benefits of the specific proposals in the paper are not clearly proposed.

The compiler should verify as much of a contract... as it can

More of the same... "as much as possible", "as much as it can"... the problem is the paper should propose some eveluationc criteria otherwise it is your word against mine. I will go with my word every time in that case.

Perhaps the most useful example [of coercive typing] is "auto-boxing" from value types to reference types

If that's the best example then... ahem. One could simply choose a language that does not even have such things that contribute nothing to the real problem.

the compiler can automatically "lift" addition on normal integers to addition on nullable integers

One could simply choose a language that does not even have such things that contribute nothing to the real problem.

[generics make it] possible to create highly reusable languages, while maintaining the benefits of compile-time type checking

Those benefits have a cost. The point is people disagree on the accounting of the cost/benifit ratios. The paper does not propose an accounting that can be examined.

I want lazy evaluation... the power of the Unix shell lies in the fact that programs consume and produce lazy streams

Agreed. But this has nothing to do with type checking. Maybe this would make a better paper than one on type checking for many readers.

Overall the paper has some ideas on how typical type checkers for C# and Java can be improved. That these checking approaches would be better than "dynamic" languages seems to be an assumption the authors chose not to question. Too bad, I thought that was the point. I don't see many people arguing to stick with the poor checking done currently by C# and Java.

T Revival

I am not sure how much this matters today, but the T Project from Yale is being revived. T is a dialect of Scheme whose optimizing compiler was a fascinating piece of work 10 years ago and influenced subsequent work on compilation via continuations.

Jonathan Rees has more interesting T background from the insider's view.

T ran on Apollo workstations among other systems. I used them at Mentor Graphics until Gambit Scheme came along.

Emacs: The Extensible, Customizable Display Editor

I had used Emacs for a couple of years or so when I came across this paper in a book on programming environments. This inspired a lot of my subsequent software design in several domains far from text editing.

Another Radically Tailorable Resource

Avi adopted the phrase "radically tailorable". Great. I like that phrase quite a bit.

Here's another reference that has influenced my thinking long before this post. This should also be in the Lieberary, but some links seem broken.

This paper presents a kit called EZWin, which provides many services common to implementing a wide variety of interfaces, described as generalized editors for sets of graphical objects. An individual application is programmed simply by creating objects to represent the interface itself, each kind of graphical object, and each command. A unique interaction style is established which is insensitive to whether commands are chosen before or after their arguments.

The system anticipates the types of arguments needed by commands, preventing selection mistakes which are a common source of frustrating errors. Displayed objects are made "mouse-sensitive" only if selection of the object is appropriate in the current context. The implementation of a graphical interface for a computer network simulation is described to illustrate how EZWin works.

Longhorn and RSS???

This violates all sense of design. Is this their latest attempt to make a "new OS" compelling? What would a sensible developer think about "putting RSS into Linux"? What could that possibly mean that was advantageous to *anyone*???

Programming RSS and Atom

Here is at least one more blog reference to Danny Ayer's book. (re: This first reference.)

I just got it recently and so far so good. A variety of topics and apparently useful core information.

Another good book seems to be Developing Feeds with RSS and Atom, by Ben Hammersley. That one seems to stay more to the core though I've barely cracked either of them.

At least two more with similarly sounding titles are on their way.

"In XML format" ==> Still not enough information

Update: Brian Jones has a blog with more information. Not a whole lot more yet, but more. For example the default stroage will be zipped XML. The XML will be "fully documented". A royalty-free license is mentioned with no hints as to what it provides. However on their press site comes this encourage news...

PressPass: Won't this make it easier for your competitors to copy Microsoft Office?

Sinofsky: Certainly this will make it easier for other developers to use our formats to build solutions that don't require Office. However, the ability of other technology providers to use the new file format to integrate their solutions with the Microsoft Office System is an important and frequently requested capability by the industry. We feel it's to everyone's advantage to respond. Customers also know that the true value of a desktop application is not the format in which data is stored but the full breadth of capabilities offered by that application, along with the quality and security of the user experience that it provides.

So now I mainly wonder a few things...

• Hopefully "fully documented" means what you would hope it means.
• Hopefully "other technology providers to use the new file format to integrate" means what you hope it would mean.
• Hopefully, since they apparently will not support Open Document format, "integration" is as easy as you would hope it would be.

Hopefully. End Update

What does it mean these days to anyone knowledgeable enough to care to say that you store your data "in XML format" without saying anything meaningful about what that format actually is.

My interpretation of this contentless "news" about content is that it serves as FUD given the recent ballyhoo about OASIS and the Open Document format. I have seen no other meaningful information to suggest an alternative explanation.

Unwittingly the typical customer says, "Why switch to another office suite when Microsoft is also publishing 'in XML format'".

Eek

A tag line found on Danny Ayers blog...

Tags: hReview, microformats, microformat, rdf

Is there something concerning about this?

Not Scheming

Mark Baker suggests about web description languages...

I generally think it's a bad idea to describe the data produced using a schema since schemas generally (DaveO's excellent extensibility advice notwithstanding) change foreseeably over time, and I don't want a change in the schema produced by a service breaking clients if I can help it. Instead, I'm more a fan of simply using a media type as a name for an open-ended sequence of backwards-compatible schemas (think "text/html" vs. HTML 2.0, 3.2, 4.01, etc..), as well as, of course, associating an extensible processing model to that media type to accomodate as many unanticipated extensions as possible over time.

These monkeys...

...wannabe something else.

But they're not.

Dance, monkeys, dance.

Good Point

Chris Sells makes a, er, "point"...

The thing that I really need that I'm missing is for my computer, and everyone's computer that I'm conferencing with, to have a stylus attached to their screen. The "let's just sketch something on the white board" is really the last remote collaboration frontier 'til we get some kind of fancy "virtual presence" stuff going.

I don't mean that every computer needs to be a Tablet PC. Frankly, I'm not very productive on a computer that doesn't have a keyboard. But, I want to be able to sketch something right on my computer screen like a tablet can and instantly share it as I do so. Plus, and here's the rub, I want everyone else to have a stylus, too. If they don't, they'll turn to the white board and I'm out of luck across the great divide.

Good point. A freehand drawing and handwriting surface should "just be" part of the standard desktop.

In the Loops

Martin Fowler looks for a rigoruous definition of "agile" software development practices, and measurements of which practices may be more effective than others.

...agile methods fundamentally expect teams to decide what process to follow and furthermore expect teams to actively and regularly change their process. Any attempt to define a rigorous process that can be tested for conformance runs contrary to this philosophy...

How can you do a survey on whether agile methods are more effective that alternatives, or whether Extreme Programming is more effective than Scrum, when you can't get a clear definition of what Scrum is in the first place? If a client wants a system built using Extreme Programming how can they tell if it's really being done?

The first part of the quote above *is* the definition of agile in my experience: if the team decides what to follow and actively improves their performance then they are "being agile". The second part of the quote becomes less interesting in this case.

Comparing textbook definitions to each other is less interesting than comparing an agile team to its own history. If the team is improving then that's the goal.

A useful excercise for a team when considering their own agility is for them to explicitly describe their feedback loops (plural), who should be in their loops for which information, and how are decisions (and their timing) made in each of these loops.

(Hint: many problems in an organization of any size occur, and are therefore obscured, outside the boundaries or on the border of the "team" per se.)

Using this approach Scrum, XP, and other approaches become possible sources of improvement and less a necessarily well-defined instruction manual that can be graded independent of actual performance.

And the Sith Came Tumbling Down

James Robertson defeats the Dark Side with one simple observation...

The characters made stupid choices again and again. Not to mention the improbability surrounding the central fear point of the movie, that Padme would die in childbirth. Apparently, hyperdrive is one thing in the Star Wars galaxy, but knowledge of C-Sections - nope.

Anakin's response: "Oh. Yeah. Good idea."

Still Crazy After All These Years

Via the Utne Reader...

This week Halliburton holds its annual shareholders meeting at the Four Seasons Hotel in Houston. Attendees will toast a whopping 25 percent overall revenue growth thanks to recent work in Iraq. Others will gather outside the swank hotel to protest corporate-cronyism and war-profiteering.

Accountability? America needs you, Harry Truman

SAP, Python, and Passion

Yet?

"Open-source technologies such as Python and PHP, to name just two, are of great interest to college students and younger people with a passion," according to Shai Agassi of SAP's Executive Board. But he doesn't believe there is yet the same enthusiasm for ERP (Enterprise Resource Planning) applications.

Evidence the long-tail may be gaining mind share over the SOA?

Orange Billion Dollars

A.F. reports...

Maher followed by asking Coleman if it struck him as odd that there haven’t been any terror alerts since the election?

After a long laugh from the audience, Coleman answered with some stuff about there still being a high level alert, but then reassured everybody with: "If in fact people used these things for political purposes, I’m sure Congress will look into that."...

Meanwhile, the Coalition Provisional Authority, which we ran, has lost 8.8 billion dollars. By lost, I mean it’s totally unaccounted for. Not only has Congress not "looked into" this $8.8 billion and who might have it now, but it seems that some members are completely unaware that this staggering sum, which was supposed to go toward rebuilding Iraq, is missing. The Sunday morning after the White House Correspondents dinner, I ran into Senator George Allen at a brunch thrown by John McLaughlin and his wife. Allen had never heard of the missing $8.8 billion, or at least that's what he told me. And he's on the Senate Foreign Relations Committee.

Stunned, I went up to Susan Page of USA Today and her husband Carl Lubsdorf of the Dallas Morning News, two veteran Washington political reporters, and told them about Allen’s ignorance of this huge scandal, which has no doubt contributed to hatred for America and the deaths of our troops. There’s less electricity in Iraq now than there was before we invaded Iraq.

Turns out that Page and Lubsdorf had also never heard of the unaccounted-for $8.8 billion. For a moment I thought that maybe I had been imagining things.

Then I spotted my friend Norm Ornstein, scholar from the American Enterprise Institute. "Would you believe it if Norm Ornstein told you about the $8.8 billion?" I asked Susan and Carl.

"Sure."

I brought Norm over, and indeed I had not been imagining things. "It was a huge story," Norm told them.

"Was it in the New York Times?" Carl asked Norm.

"Yes," Norm assured him.

Five Percent

Howard Dean on the Senate...

One of the great geniuses of American democracy, unlike most of the democracies in the world that minority rights are protected, 48 percent of us didn't vote for President Bush, but we still have some say in shaping the agenda of the country. If the filibuster is gotten rid of, the extended debate is gotten rid of in the Senate, first of all, it means the president can put 10 judges on the bench that we believe are not qualified to serve. We've confirmed 205 of his judges. He wants those last 10, so they're willing to change the rules to do it.

But it has much worse implications.

Touch Enough

A.H. observes Tim Russert "interviewing" Howard Dean. As a counterpoint to my last post, what happens when a Democrat does try to really talk about the war in a national forum...

The key exchange came when Dean raised the most critical point about Iraq:

DEAN: Because of the president’s actions, I would argue that we are in greater danger now because of what’s going on in Iraq than we were before. Now there are terrorists in Iraq. They have migrated there since our troops were there.

RUSSERT: Let me stay on your rhetoric…

Nice pivot, Tim. Yes, by all means, let’s stay on Dean’s rhetoric rather than on the insignificant fact that our country is less safe as a result of our invasion of Iraq. Good to see you’ve got your priorities in order.

Another reason why I don't watch "major" news networks.

As I write this one of the best programs for real news and interviews... Democracy Now is on my TV, on a local community cable channel from 5am to 6am M-F. But you can watch it on the Internet too.

Slip Sliding Away

James Boyce writes...

The fact that thousands of young men and women are coming home disabled for life and learning to live on $2,000 a month disability is a disgrace. The future security of our country is at stake because, as an Army recruiter was explaining on a talk show the other night, this is the first “real” extended war the volunteer army has had to fight, and recruiting to actually fight is different than recruiting to train to fight...

I spoke with a top Democratic fundraiser, smart guy, best of the best, and I quote: “The Democratic consultants here in Washington are convinced that the 2008 election will be all about domestic issues.” Sure it will be. Just like the last one was.

POO

Joe Gregorio (BitWorking) smells a missed opportunity...

Personally I think he missed a great opportunity to name it Post Only Once.

Ballmeristic

Steve Ballmer of Microsoft sez of RSS (which one?)...

It is a little too simple, that is also the reason everyone’s using it. We are working on more existing powerful stuff, around XML/web services [sic] that will address many issues beyond RSS. RSS will be around, but whatever we are working next will be cooler and more prevelant.

(via James Robertson)

muf

Eric Meyer writes...

What’s fascinating is how fired up people get about microformats.

I'm kind of fired up.

More Data

IEEE Computer May 5, 2005 Beyond the Relational Database Model David M. Kroenke, University of Washington Former VP of Development at Microrim (R:Base 5000) pp. 89-90

During the next hour or so, I walked her through the process of creating five normalized tables - Customer, Salesperson, Invoice, Line Item, and Item - and hooking them together with foreign keys. Then I explained how to rejoin them to get her sales order back. Long into the call, she asked, "Why am I doing this?"...

After 35 years of computer science and numerous iterations of Moore's 18-month cycles, isn't there a better way?

Data

Communications of the ACM
Volume 48, Number 5 (2005), Pages 111-118
The Lowell database research self-assessment

It is time to stop grafting new constructs onto the traditional architecture of the past. Instead, we should rethink basic DBMS architecture with an eye toward supporting:

• Structured data;
• Text, space, time, image, and multimedia data;
• Procedural data; that is, data types and the methods that encapsulate them;
• Triggers; and
• Data streams and queues

as co-equal first-class components within the DBMS architecture—both its interface and its implementation—rather than as afterthoughts grafted onto a relational core...

Many new applications that use DBMSs are going to require unattended operation. In addition to no-knobs tuning, the DBMS must be able to recognize internal malfunctions and malfunctions of communicating components, identify data corruption, detect application failures, and do something about them. Such capabilities require making the DBMS more self-aware and providing it with explicit models of the information system in which it participates...

A small number of slick visualization systems oriented toward information presentation were proposed during the 1980s, notably QBE and VisiCalc. There have not been comparable advances in the last 15 years, and there is a substantial need for better ideas in this area.

Thirty years of research on query languages can be summarized by "we have moved from SQL to XQuery."

First, the database research community should avoid drawing too narrow a box around what we do. We must explore opportunities for combining database and related technologies that can improve the usage of information, such as information visualization technologies, which has often been left to the domain of other research communities. To broaden the set of technologies database researchers apply, they need to expand their breadth of competencies. Consider the plasterers' union, which decided many years ago, when wallboard was being introduced, that it was not their competency. As plaster was replaced by wallboard, the union lost out. This fate could befall the DBMS community if it does not respond to the new challenges of integrating related technologies with information management.

Second, it was noted that the average age of participants at these meetings has been increasing. On the other hand, there are more young database researchers than ever before, as evidenced by the large number of junior faculty in databases. We recommend the next meeting invite a broader mix of age groups within our community.

Coordination vs. Command and Control

From Vanessa Williams we get...

For my taste, Web Services and SOA architecture puts too much emphasis on centralized orchestration and not enough on self-organized, coordinated behaviour in large open systems.

No Regrets

Update: See my response to the comments if you're interested.

I have no regrets having dropped Newsweek about a year ago, what with the Bush administration CBS'ing them and Newsweek having no more backbone than the other "mainstream" corporate media so-called "news" agencies.

For their good behavior, I'm giving Newsweek and its owner, the Washington Post, this week's Yellow Streak Award for Craven Cowardice in Journalism.

As always, the competition is fierce, but Newsweek takes the honors by backing down on Mike Isakoff's exposé of cruelity, racism and just plain bone-headed incompetence by the US military at the Guantanamo prison camp.

Isakoff cited a reliable source that among the neat little "interrogation" techniques used to break down Muslim prisoners was putting a copy of the Koran into a toilet.

In the old days, Isakoff's discovery would have led to Congressional investigations of the perpetrators of such official offence. The Koran-flushers would have been flushed from the military, panels would have been impaneled and Isakoff would have collected his Pulitzer.

No more. Instead of nailing the wrong-doers, the Bush Administration went after the guy who reported the crime, Isakoff...

Have some sympathy for Isakoff: Mike's one darn good reporter, but as an inmate at the Post/Newsweek facilities, his ability to send out serious communications to the rest of the world are limited.

A few years ago, while I was tracking the influence of the power industry on Washington, Isakoff gave me some hard, hot stuff on Bill Clinton -- not the cheap intern-under-the-desk gossip -- but an FBI report for me to publish in the Guardian in England.

I asked Isakoff why he didn't put it in Newsweek or in the Post.

He said, when it comes to issues of substance, "No one gives a shit" -- not the readers, and especially not the editors who assume that their US target audience is small-minded, ignorant and wants to stay that way.

That doesn't leave a lot of time, money or courage for real reporting. And woe to those who practice real journalism. As with CBS's retraction of Dan Rather's report on Bush's draft-dodging, Newsweek's diving to the mat on Guantanamo acts as a warning to all journalists who step out of line.

Newsweek has now publicly committed to having its reports vetted by Rumsfeld's Defense Department before publication. Why not just print Rumsfeld's press releases and eliminate the middleman, the reporter?

The term "pussy whipped" comes to mind.

Delicious

A.H. wonders...

Wouldn’t it be delicious if the female orgasm were the thing that tips the scales in favor of the Intelligent Design crowd? It would make for a great closing argument: "The female orgasm is so complex and strange, it could only have come from God. The reason there is no evolutionary purpose to it is because there is no evolution! God is in the details... and the bedroom. Who needs Darwin when you have the Bible -- and the Jack Rabbit (grown ups only). Case closed. Amen."