Glitz and Cairo

Two interesting projects, Glitz and Cairo, based in part on OpenGL and so apparently have some cross-platform potential.

Miguel de Icaza refers to a mindblowing demo.

Why Not Try The Road Less Travelled?

Phil Windley writes...

I was having a discussion with some engineers about what languages to use in various portions of a project. There was a core piece that really needs to be optimized for performance to the greatest extent possible and other parts where cross-platform and user interface issues dominate. I began to realize that almost no recent development in programming languages helps with the former. We're probably still going to write it in C++, with all its warts, so that we can compile it.

Oh my. At least read this PDF first, especially the section by Jonathan Sobel.

What do *they* want ?

Mensa

Some interesting aspects of this item on SAP and Microsoft...

• Microsoft's code name for itself is apparently "Mensa"
• "Mensa has historically had difficulty in managing remote R&D"
• Why have a code name for an entity otherwise identified as being the "largest" provider of "enterprise applications" from "Walldorf, Germany"?

Go Tuple Spaces

"Every thing you book on Orbitz runs on a Jini backplane."

Hosting Opportunities for Smalltalk Applications?

I have a domain (http://www.stardecisions.com) that is not ideally suited for hosting a Smalltalk application.

Any ideas for an alternative, that's also relatively low cost? (i.e. I'd like it to be reliable, but don't need a lot of resources or water-tight guarantees. This is non-profit.)

Croquet

Looks like Croquet may be released soon.

Insert stupid foot-in-mouth statement like "Cupertino and Redmond, start your photocopiers".

Shades of Agenda

David Buck has open sourced (is that a verb?) a date parser in Smalltalk that could come in handy in an Agenda-like capability to cull dates out of free-form or semi-structured text.

  DateStringCompiler readFrom: 'today'
  DateStringCompiler readFrom: 'tomorrow'
  DateStringCompiler readFrom: 'yesterday'
  DateStringCompiler readFrom: 'last week'
  DateStringCompiler readFrom: 'next week'
  DateStringCompiler readFrom: 'friday'
  DateStringCompiler readFrom: 'next friday'
  DateStringCompiler readFrom: 'last friday'
  DateStringCompiler readFrom: 'Jan 3, 2004'
  DateStringCompiler readFrom: 'January 3, 2004'
  DateStringCompiler readFrom: '12/25/2005'

Disappearing the Fabric

I guess BOA means "Business Oriented Architecture"? In any case the following from Juval Lowy makes sense...

The idea behind BOA is a technology that bridges the gap between the business analyst expert and the SOA developer. BOA will have to not only interoperate with a long tail of legacy technologies, it will also have to interoperate with BizTalk, and do so without constricting itself too much. Clearly BOA will use standard patterns like Indigo Marks. I don’t think that BML (pronounced bimmel, Business Markup Language. XML for MBAs) is something we should care about because I really hope for some visual tool to do that for me.

I think we as developers can build an infrastructure that can turn 50-80 percent of business automation development over to the MBA's that otherwise would be twiddling with Excel and Access. If you know an associate who's non-technical but has built a golf tournament application with some forms and reports, they should be able to define, test, and deploy a distributed, collaborative operational and analytical business process used concurrently by dozens of people inside and out of their legal corporation.

We just have to give them the fabric to stitch together. And like Juval says, we can't give them XML or SQL. We have to make collaborative system definition, test, and deployment even easier than building in Excel and Access for the single user.

If Microsoft has something in the works that will really reduce the number of technical developers necessary to deploy a collaborative enterprise system, great. Less C#, more BOA!

What is an OS, after all, esp. in an SOA?

Wes suggests...

Part of the problem is that natural language support is a time-consuming and specialized endeavor, especially if multiple languages are to be supported. It should be in the operating system...

Why would this be "in the operating system"?

This could be a "service" that would fit well into a service-oriented architecture. As such it could be OS-independent, run locally or on the LAN or Internet. Also as such services could compete (e.g. in a blackboard), cooperate (also in a blackboard), and/or evolve independently (e.g. in a service-oriented architecture).

Update: Wes responds...

The problem is that natural language support requires maximum performance and should be available offline. In an application that uses it, the functionality will be tightly integrated with the operation of the application. It should be available as library in the same way OpenGL or data access libraries are available in Windows today.

I can see that a natural language service would be compute-intensive and memory intensive. I don't see the connection between an application and the service being so intensive though. The communication bandwidth it seems could be relatively small compared to the space and time of computing results.

Combine this with the need for a high rate of evolution of the capability itself and the result is a need for flexibility at the component interface. Why rely on one vendor for this, even if it is Microsoft?

As for offline capability, I agree, but don't we need a general offline capability with many kinds of services? A service-oriented architecture should not be considered always-connected and always-remote.

Finally comparing this to OpenGL --- I suspect the high bandwith needed between the 3D engine and the display device is a different characteristic than natural language interpretation. Isn't NL a relatively isolated computational problem?

Inflection Points and Flexible Software

Jim writes about Microsoft's inflection point...

If the perceived migration cost to LongHorn is high, then Mac OS X and Linux are going to get real evaluations.

Or even better for Jim and Cincom, viable cross-platform solutions may have more opportunities.