“Jon Udell” wrote in message
news:3B4B2DC3.796B82ED@monad.net…
> bgsmith@bendcable.com wrote:
> > It is also interesting to read Dave Winer’s perspective:
I did. And I don’t entirely agree with Dave. 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 its 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). Its 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 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).
One issue I realize that comes up is having to know what language environment (or app) is on what TCP port. This could get really busy (with 100s of ports used by running pieces of applications). One idea I was toying with was developing SOAP over multicast IP in machine. That way the SOAP requests would travel over more of a data bus architecture than a point-to-point (HTTP) architecture and each language environment could listen and grab appropriate request/replies (kind of like an ethernet).
Take this across a network and things get really cool 😉 (BTW: I realize that some of this kind of work is actually being done by the XML Protocol (XMLP) group at the W3C)
What I find particularly hopeful (if quixotic) about Mono is that it aims to bring an open source CLR not just to Unix/Linux, but to Windows as well. And not just the CLR, but key .NET Framework ingredients like WinForms and ADO.NET, which are excluded from the MS shared-source version.
If you think all this stuff defines the next-generation platform, client-side as well server-side — and I do — then it’s imperative to have a fully open version, and in fact it matters more on Windows, in my view, although that is not Mono’s primary objective of course.
If the open source approach does not get unleashed on the client side in a major way, but confines itself purely to the realm of cloud services, then open source can remain viable, but will be missing its largest opportunity.
Gregor J. Rothfuss 