Tangled in the Threads
Jon Udell, July 11, 2001.NET Everywhere?
Both Microsoft and Ximian announce new implementations of .NET
Last winter I wrote a couple of articles outlining why I think .NET is important. Most crucially, in my view, .NET represents an historic convergence between two great themes in the recent history of software development: objects, and components.
Admittedly, you have to dig through a lot of layers of Microsoft marketing to reach this conclusion. At the core of the onion sits the .NET Common Language Runtime (CLR), which is a universal object programming engine -- something that the Java Virtual Machine might have been, but isn't. Wrapped around the CLR is a framework of classes, and a toolset. These aim to update the now-conventional notion of a component as a COM object to the more modern notion of a component as a web service.
The unification of these themes -- objects and components -- is a huge deal. I think it will profoundly alter the face of software development. And therefore, I've been suggesting for some time now that this technology cannot be tied to the Windows platform, or to Microsoft.
Ask and ye shall receive! On June 27, Microsoft announced its "shared source" implementation of the CLR and its core classes, for Windows and also FreeBSD. I noted the event by posting, to my newsgroup, a reference to an O'Reilly Network interview with Microsoft's shared-source-.NET guy, Dave Stutz. This was Brian Sobolak's response to the newsgroup:
The burning question in my mind, which this article doesn't really address, is if this creates the opportunity to run Visual Basic code on Unix. It does mention Windows Forms, but as far as I know, Windows Forms is a specific part of ASP.NET.
The lack of Visual Basic is a serious impediment to the adoption of Linux/Unix by developers. There are so many Visual Basic developers out there and for better or for worse, there is a lot of business logic contained in VB too. I'm interested to see where they draw the line for VB.NET support and how well VB.NET will actually work on a free FreeBSD implementation or (if it exists) a commercial CLI implementation for Solaris.
WinForms isn't part of ASP.NET, but yes, it's a GUI framework that's separate from the CLR and base classes, and specifically excluded from the shared-source version that Microsoft announced.
I then commented:
I think there's another shoe still to drop. I'm not sure just what "shared source" is going to turn out to mean. But in any case, if the core .NET technology becomes as important as I suspect it might be, there will (in my view) have to be multiple implementations, including a strong purely open source one.
Lo and behold, on July 9 the other shoe did drop. Ximian announced Mono, a project to develop a true open-source implementation of .NET. Significantly, it aims to include some of the framework pieces excluded from the Microsoft version: WinForms, ADO.NET.
Although Microsoft's license for the shared-source .NET has not yet been revealed, Ximian is taking no chances. In a note to contributors, Ximian says:
If you have looked at Microsoft's implementation of .NET or their shared source code, you may not be able to contribute to Mono. Details will follow when we know more about this.
In general be careful when you are implementing free software and you have access to proprietary code. We need to make sure that we are not using someone else's copyrighted code accidentally.
Client-side vs server-side .NET
Several newsgroup correspondents referred to Dave Winer's essay on the Mono announcement, which concludes:
Any scripting language can be boosted to .NET-competitive status simply by making SOAP 1.1 and XML-RPC support a standard part of the install and docs. Hardly any technical work is needed.
In other words Python is already a worthy competitor to .NET. Anyone developing in Python should know they don't have to budge an inch to be part of the new network. Same with every other scripting language and environment. There's no reason to switch or freeze or wait. Get unconfused now.
I know just what Dave means, and I partly agree. It was a revelation the first time I worked on a multilanguage project where XML-RPC, sitting in the middle, made the differences between Perl (on one server) and Python (on another) disappear.
But .NET is about more than SOAP services in the cloud. It's about applications that run locally, with GUIs, too -- applications that enable folks to interact with those web services. Sure, cloud-based services are, and will continue to be, consumable by the first-generation universal web client -- the HTML/JavaScript browser. But there's going to have to be a more capable next-generation successor to that client platform. It wasn't ActiveX. It wasn't Java. It wasn't DHTML. I have a feeling it just might end up being WinForms.
You can think of WinForms as MFC (Microsoft Foundation Classes) for scripting. As such, it represents another kind of historic convergence. A bunch of Windows apps are written in C++, using MFC. A different bunch of Windows apps are written in Visual Basic. Shouldn't the robustness and flexibility of the former approach be combined with the productivity of the latter? And shouldn't the combination of all these virtues be available on any platform, and from any language?
I think the answer to these questions is clearly yes. There is, however, a lot of technical work still required to realize this dream. Even if you look at Python purely from a web-services perspective, it's not in itself a "worthy competitor to .NET." True, you can easily produce and consume web services in Python, by way of SOAP or XML-RPC libraries. But while such services may be implemented as objects, they are Python objects that are not extensible from other languages. One of .NET's goals is precisely that Python -- like Perl, or JavaScript, or C#, or another language -- becomes an interface to a universal object system. Whether this pans out remains to be seen, of course. Early experimentation at ActiveState suggests that the CLR will need to adapt to the needs of dynamic languages, like Perl and Python, before the benefits of a universal object system can be realized. I hope this will eventually happen, and if it does, that we'll come to regard programming languages not as competitors, but as alternative -- and deeply interoperable -- ways of describing and implementing software.
Next, consider Python from a GUI perspective. Suppose you want to write an app that helps people interact with some Hailstorm service. You're in luck, actually, because there happens to be an outstanding GUI toolkit, wxPython, which builds upon wxWindows, a cross-platform GUI toolkit. The roadmap isn't so clear for Perl programmers, though. There's a wxPerl, but that project isn't as active as wxPython. In general, there's no clear strategy for how open-source scripters should develop portable GUI apps, and no strategy at all for doing so in a language-neutral way.
That's why I think Ximian's plan to include WinForms is so crucial. This is, after all, the company that's working to make GNOME a first-class desktop environment, and to populate that environment with productivity apps like Evolution (GNOME's answer to Microsoft Outlook). As Ximian's Miguel de Icaza has explained, productive tools for developers are the key to productivity apps for users. The web flourished thanks to the amazing productivity of open-source scripting. Imagine what things would have been like if every CGI program had to be written in C++. Yet by and large, that's still how we approach client software. The .NET WinForms framework aims to raise the level of abstraction in this game. Microsoft's implementation will likely become pervasive. So it's not only a problem for Linux users if Linux developers can't target this platform. It's a problem for everybody, because Windows users need hiqh-quality open-source software just as much as Linux users do. And there are, of course, a whole lot more Windows users. It would be great if open-source programmers could routinely and easily produce apps for both platforms.
Near-term strategies
Whatever happens with WinForms is, in any case, some distance away. But apps need to be written today. There isn't a clear choice for a portable GUI, unless you think that Java qualifies. And there are no language-neutral options -- or are there? Here's a pragmatic approach:
Rich Kilmer:
Once you start thinking in terms of web services (and your language supports this in a seamless way) a whole lot of cross-language problems just go away. Now, this may not be the best performer (having SOAP flying around in-machine) but it really DOES work. I like it because it's a loose integration ("objects" invoking each other via HTTP).
I have a desktop app right now that has a process running in Ruby and one running in Visual Basic and they communicate with each other via HTTP in machine (both Ruby and VB have their own web servers). It's not even SOAP yet, but that's my direction. I do all the complex OO stuff in Ruby, and use VB for a nice (native) UI wrapper (so I don't have to try and integrate the Win32 API into my Ruby app or use TK). The VB stuff is only going to take about 3 weeks to write. If I move this app to another platform, I just throw away the VB part and replace it with something for that platform (like Objective C or Java on Mac OS/X). The app works wonders...with Ruby dynamically serving HTML to the ActiveX IE control wrapped in a native Windows application (complete with task bar integration, OLE drag-n-drop, and desktop toolbars).
We tend to dismiss the notion of in-the-box SOAP (or XML-RPC), for performance reasons, but as Rich points out, its quite attractive in other respects. And when the communicating objects are coarse and the protocol not too chatty, it can work out nicely.
I then wondered if we'll see the emergence, for .NET, of something like the Windows LRPC (lightweight remote procedure call) mechanism. The idea here is that you pretend to always be doing socket-based remote procedure calls, but when both endpoints are local, there's a hotrod path through shared memory. I haven't heard of anything like this in connection with .NET and SOAP, but it might make sense. Instead of just marking some methods with the [WebMethod] pragma, as you do now in .NET to activate SOAP's marshalling machinery, everything would be implicitly that way, but on demand. The SOAP machinery would get optimized away in the local case.
Colin Sampaleanu:
I think you may be missing part of the .NET picture. There is actually the web services support in ASP.NET, which allows you to expose things as SOAP web services, via a [WebService] attribute, but there is also an unrelated (hard to believe they don't share common code, but they were separate groups at Microsoft) piece called .NET Remoting, which allows you to expose any piece of a CLI object in a somewhat similar fashion, but the interesting thing is that you can change the transport and the encoding. So there is an implementation that uses HTTP and SOAP, and there is also one that uses raw TCP and a binary encoding, that is pretty much faster. And if you want, you can supply your own transport or encoding. All this is configurable/accessible programmatically and also via (XML) config file. Somewhat like a better thought out version of Java RMI. Pretty cool...
Thanks Colin! I had read about, but never tried (and so, forgotten about) .NET Remoting. In any case, the big picture seems clear to me. Software has long been defined in terms of insular communities -- defined by OS platform, along one axis, and by programming language, along another. Programmers are not well served by this arrangement, and users less so. Microsoft has, in .NET, staked out a future that places objects, components, and services at the forefront. I'm sure this is the right future. But we can't allow Microsoft alone to define it. We're talking about foundation technology here. To be healthy, the software industry and the Internet ecology -- two things that are becoming the same -- will require that multiple implementations of .NET exist, and that competition can occur. It's great to see things moving that way.
Jon Udell (http://udell.roninhouse.com/) was BYTE Magazine's executive editor for new media, the architect of the original www.byte.com, and author of BYTE's Web Project column. He is the author of Practical Internet Groupware, from O'Reilly and Associates. Jon now works as an independent Web/Internet consultant. His recent BYTE.com columns are archived at http://www.byte.com/tangled/
This work is licensed under a
Creative Commons License.