Month: July 2001

Web services metering

IBM makes a distinction between free web services with no service level agreements, and web services for business transactions. They envision a wide variety of business models for this, including

The pay-per-click/fee-for-use model
The subscription model
The lease model

their resource counter can create a wealth of information and output it in a new xml format for usage records developed by ipdr.org

obviously this needs to be integrated with uddi, and open api’s need to be developed so that this can be seamlessly integrated with the overall architecture. i hope it does not mean a worldwide roll out of a pki infrastructure, though. that would suck given the pki adoption track record. Their paper is at developerworks.

Apple SOAP

apple quietly put in SOAP support in their updated apple script environment for OS X 10.1. now we are cooking. the (self declared) “biggest UNIX vendor by the end of the year” joins the frenzy that is SOAP. welcome apple. with so much support under its belt, SOAP will be ubiquitous before you know whats going on.

In Wired

Gregor, our brother-in-geekness from Switzerland, reports that his country-folk are yokels when it comes to anything cyber and notices a lot of raised eyebrows around his Zurich neighborhood when he starts off on one of his technocratic rants. Mercifully, the Net provides this Web builder with an escape from this provincial hinterland and connects him to kindred spirits, who share his homicidal aversion to spammers and his faith in the future of digital democracies.

Funny intro I have to say. While switzerland is a little less provincial when it comes to technology these days, the raised eyebrows stuff has not changed 🙂

Anyways, the article is still online.

Technical webcasts

killing some time at the office, i came across technetcast.com which has some good webcasts available for download. the top 30 streams are:

.net beta 2 first impressions

scott guthrie (ms):

Our goal with Beta2 is to have as high-quality release as possible. Specifically, we have decided to not postpone any bugs to be fixed after the Beta2 milestone — and instead try to get all known V1 bugs fixed for the beta2 release. An ambitious goal — but one that we think will really deliver a great quality product.
We are also doing a lot of work to make sure that ASP.NET Beta2 will support production deployment of high-volume projects. Specifically, we are working with 11 MSN Applications (each with a significant customer volume) that will go live before Beta2 ships — to allow us to find any nasty stress issues remaining (ones that just don’t show up in a simulated test lab).

it looks like MS did their homework on this release. a quick look into the help files does not show any TBDs like it did with beta 1. also, many stupid bugs that were in visual studio beta 1 seem to have been eliminated. i think that with the missing docs in place and critical bugs fixed, .net will reveal its secrets more willingly than before.

Critical Discussion Tools for the Web

Developed for the Foresight Institute to enable critical discussions and enhance productivity for those using the web, CritSuite takes vital steps toward a truly connected and interactive Web structure.

CritSuite consists of 3 pieces of integrated software which allow individuals to comment on and view existing hypertext documents (CritLink), to navigate the Web using a graphical interface (CritMap), and to archive email exchanges using the features of hypertext (CritMail).

Web navigation using CritSuite may be accomplished in 1 of 3 ways: by following a link in the document being viewed in the browser; by entering an URL in the CritLink location field at the top of each screen; or by selecting a link directly using the visual interface of CritMap. Each of the navigation methods are synchronized, i.e. when a new link is selected, CritLink and CritMap will each display the new site.

xanadu architecture

In the Beginning was the Docuverse: The docuverse can be thought of as a infinite number line with all the information it contains or ever will contain strung out along the line. Since the number line is infinitely divisible, we can insert new material at any point, similar to how real numbers work on a number line. We can also refer to a portion of the information, whether it exists today or will someday, using a (position, width) tuple.

Reliable HTTP

A bit unclear why this is needed:

Reliable HTTP (HTTPR) is a new protocol that offers the reliable delivery of HTTP packets between the server and client. This solves a number of issues that are evident in current HTTP and opens the way to reliable messaging between Web services.

Cut the 3G crap

Why not build innovative mobile apps with 2G technologies instead of whining about UTMS?

Esther Dyson:

We were driving to a board meeting in Tallinn, Estonia. When we arrived at our destination, Juri Kaljundi picked up his cell phone. “Gotta warn them we’re here?” I joked? “No, I’m parking,” he answered. He was sending an SMS to the city’s parking service. Based on his cell phone number and the license number and the location he entered, the parking service database would register his car as parked, and bill him at a rate tied to the location and time. Later, when a meter minder came by, the minder would see a “mobile parking” sticker on Juri’s windshield and could send another SMS, including the car’s license number. As long as Juri had registered as parked, no problem. Otherwise, the system would fine him for parking without registering.

Estonia is evidence that the current mobile network is just fine for all kinds of cool applications. Imagine what could have been done with all that money that was sunk into 3G licenses by investing it into cool ideas like these? Obviously, there is a shortage of smart ideas and an abundance of capital. I see no other explanation for the recent dumb investments.

SOAP for local app integration

“Jon Udell” wrote in message

news:3B4B2DC3.796B82ED@monad.net…

> bgsmith@bendcable.com wrote:

> > It is also interesting to read Dave Winer’s perspective:

> > http://web.archive.org/web/20071116015409/http://www.scripting.com/davenet/2001/07/09/miguelDeIcaza.html

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.