Tag: architecture

The Other Road Ahead

, , , ,

Last time I argued that from a technical perspective, the “server”, “client”, and “P2P” labels were complicated. That narrow view deliberately ignored the roles that these technologies have on the user, and on communities and business built around them.

I’ve been looking back at Paul Graham’s 2001 essay on “The Other Road Ahead.” He laid out a bunch of benefits that accrued from his successful company’s use of what he called a server-based architecture. While Viaweb originally relied on generic “Web 1.0” clients not distributed by his company, his essay looked ahead to richer clients such as what would come to be known as “Web 2.0.” I think the essay applies just as well today to mixed-technology deployments like Google’s current development. And I think it applies to some Croquet deployments, including those by my employer Qwaq. A lot of what Paul describes turns out to be things we’re already doing. But by explicitly identifying the benefits and what enables them to be realized, even a peer/client-centric geek like me can appreciate the operational value of the different technologies I’d mentioned last time. From this perspective, I’d say we’re “half-server-based.”

Worth a read (as are his other essays). See if you don’t agree.

OpenLaszlo == Ajax

, , , , ,

OpenLaszlo, for which I am the documentation guy, now compiles to DHTML as well as to Macromedia Flash (swf). That means that you can take the same LZX source and compile it to either swf or DHTML, and it will just work. So there is now a completely OpenSource stack for doing web apps.

OpenLaszlo is much more robust and full featured than any other Ajax toolkit. And, the architecture includes a client abstraction layer, which means that we worry about browser inconsistencies so you don’t have to. The upshot of all this is that if you want to build a real web application, you should use OpenLaszlo instead of some Ajax toolkit. Of course if you just want to spruce up a web page, Dojo or Rico or something like that might be appropriate. But I think you would have to be nuts to use them for building a real application.

We’re not yet shipping a “production” version — that’s scheduled for “sometime in 2006”– but the prototype version is getting more robust by the day, and there is a very credible demo up on the website.

Scaling to the Enterprise (Part 4 of 4)

, , , , ,

4. HOW RELIABLE IS THE COMMUNITY?

(See part 1.)

None of the previous matters if the software isn’t useful, or if we are not allowed to use the software. The former is what we’re working on, but the latter is a very complex issue. Croquet is certainly not at critical mass. It could certainly go away. However, we feel it is immune at least from licensing plays such as those that have plagued the use of proprietary systems in higher ed, or those that have fractured the Java community. As the number of users in such systems grows, attempts for controlling proprietary lock-in have been very expensive. Croquet fights this in several ways: with an open source license in which all work on Croquet itself is available to anyone; with a P2P architecture that eliminates any advantage to “controlling the servers”; and with a dynamic language that eliminates any advantage to “controlling the release.” We feel that this last will be further strengthened by upcoming work in architecture and security, to be carried out here at UW. For the general health of the community, I look forward to upcoming announcements.

Scaling to the Enterprise (Part 3 of 4)

, , , , ,

3. HOW WILL APPLICATIONS BE DEVELOPED?
(See part 1.)

It is not practical to expect users to develop applications in Squeak. There is too much to learn. But neither is it practical to expect users to develop applications in Java or ANY OTHER COMPUTER LANGUAGE. There is no way that any community of professional developers could possibly keep up with the demand that we hope for unique applications. No matter what language they used, nor even how many developers were available. There’s simply many more users — and user needs — than there are developers. As with scalability of load, we need another approach. The answer is the same: push the load to the edge of the network.

Continue reading

components status

, , , , , , ,

I had hoped to have a usable version of the components framework by now. Instead, I have a reasonably self-consistent set of scaffolding that illustrates a lot of the concepts. It isn’t at a critical mass of functionality, and it has a lot of bugs and mis-steps. I was sure that copy semantics, multiple views, and event handling were going to be hard, as would getting enough corners tacked down so that I could start to cut the cloth. But they turned out to be much harder than I imagined. Nonetheless, I’ve now got a stake in the ground as the starting point. Maybe now there’s enough ‘it’ there that I can next report, “made ‘it’ do such-and-such”, or “added X to ‘it’.”

Below the fold is a diary/log of how I got to this point. (I originally called this a “bootstrapping” architecture, because components allow people to build their Croquet models from within Croquet itself.)

Continue reading

component programming

, , , ,

Marshall McLuhan said that the interesting thing about a medium is what it makes the user become in order to use it.

What does Croquet make people become? Rick McGear, a Croquet advocate at HP, says that using Croquet makes us become programmers.

What is programming? The classic definition is of computational processes, but object-oriented programming seems to take a different view. And Croquet’s TeaTime architecture describes objects in terms of a mapping between message histories. I’m not finding process to be satisfying.

Continue reading