wiredfool

Friday I saw the Omar Torrez Band at the Tractor Tavern.

This has to be my favorite local band – a wild combination of funk, flamenco, and cuban rhythm. There was a new lineup with Darrius Willrich on keyboard and Jesse Stern on electric bass for this show; previously they were without keyboard and had Julian on the bass.

Omar has significantly reworked his set list since the last time I saw the band. There were 4 new songs, and the old favorities had a completely new feel. There were times that I heard echos of of the old riffs floating through the new songs; almost teasing my mind to recall the previous incarnation.

From a musical standpoint, it rocked. From a “I’m comfortable with the music and I want to lose myself for the night” point of view, it was a little less satisfying. I gotta say I really liked Julian (their previous bassist), it seemed that he had more authority and a cleaner sound. That may just be familiarity though, since I did see him 3 or 4 times. Jesse had a little less control of the sound and quite a bit less of the spotlight.

April’s Seattle Frontier Users Group meeting will be held on Tuedsay the 25th, at 7pm. We will be discussing Pike and Manila, with an emphasis on the user’s point of view. We invite users and those who want to be users to come and check it out.

We will be meeting at the offices of Socialecology (my employer) at 1818 Summit. (near Denny and Olive on Capitol Hill) Email
seafug@soroos.net for directions.

*** in progress!

The sortid history of my DSL connection, or ‘why your 28.8 modem isn’t so bad’.

This site iw wired fool. There’s an explicit part of that, namely “wired” that implies that I have a connection.

Well, I parted company with my ISP recently over a disagreement about the meaning of acceptable downtime.

*** The reasoning

XML-RPC is designed to send a mime formatted message from computer to
computer via a http connection.

But alas, not everyone has connections that are sufficiently reliable to rely on
a tcp-ip connection. (such as one provided by PacBell, UsWest, Flashcom,or Conaxion) For some applications, encapsulating the xml-rpc message in
alternate transports is a necessary or acceptable alternative.

This specification covers the implementation of xml-rpc over such non-ip
based transports such as: Zip disk/Sneakernet, postit note/felines, and
small print/homing pigeon. These are not all desirable vectors, but if you
don’t have a tcp-ip connection, you don’t have a whole lot of choice, do
you?

There are some issues that need to be addressed. Once an immediate
connection is changed to an asynchronous one, there is a chance that a
failure will occur without the knowledge of either the client or the server.
For example, mixing the feline and pigeon vectors could have disastrous
results. Care should be taken at the api level to ensure that an
acceptable error mechanism is provided.

*** The spec

The request is of the form:

-- transport dependant information here. -- 
Mime-Version: 1.0
Content-Type: text/xml; charset=us-ascii
 
<?xml version="1.0"?>
<methodCall>
  <methodName>examples.getStateName</methodName>
  <params>
    <param>  
       <value><i4>5</i4></value>
       </param>
    </params>
  </methodCall>

The essential portions of this are:

• Content Type: text/xml, to distinguish it from plaintext
• Body: this is straight from the rpc spec

A Sample Reply

 
-- transport dependant information here. -- 
Mime-Version: 1.0
Content-Type: text/xml; charset=us-ascii

<?xml version="1.0"?>
  <methodResponse>
    <params>
      <param>
        <value>California</value>
      </param>
    </params>
  </methodResponse>

*** The implementation

Zip Disk/sneakernet

Of the alternatives presented, this is the most attractive. As the
immortal spaf was heard to utter way back when, “Never underestimate the
bandwidth of a trunkload of backup tapes.” This is a nearly infinite
bandwidth solution, limited only by the removable media capacity on either
end of the connection. The xml-rpc requests are written as a mime formatted
text file, and loaded on the other end. Replies are at the discretion of
the server.

Postit note/feline

This is perhaps the least effective method of getting the message across,
although it does have side effect benefits of amusing the feline owner and
passers by. Experimental evidence has shown the following: postit notes
stick reasonably well to the fur of Maine coon cats (MTBF, 20 minutes), and when put in an
area where the only off limits area is the server room, the cats will
gravitate to that room. Therefore, printing mime formatted messages on
postit notes and affixing them to cats will have a non zero probability of
the message reaching the server. However, it’s probably faster to get up
and go over to the console yourself. Warning, this could be dangerous with
surly cats.

Small Print/homing pigeon

The final method offered for review is xml-rpc via homing pigeon. Print out
a mime formatted message and affix it to a pigeon’s leg using Simpson’s
Individual Stringetts(tm). This method is not suitable for larger
messages, as it could affect the airspeed velocity of the pigeon, causing
it to not so much fly as plummet. Pigeons can be surprisingly fast
delivery vectors, although they tend to be rather imprinted for one way
delivery to a specific destination. Return messages can be delivered by
additional trained birds.

*** The Demo

I’m sorry that I don’t have a demo set up, although I’ll try to get a
picture of the cats.

*** The Caveats

This is a joke. It may work on my machine, but I wouldn’t bet on it. Any
resemblance to any spec, living or dead, is purely an aberration. However,
I wasn’t kidding about the postit notes. Actually, the sneaker net thing
would work, but there are better ways to do this.

*** The Legal Stuff

There is no warranty. There is no patent. If you use these ideas, you’re a
far braver man than I. My employer, “Socialecology”, has no foreknowledge of
this posting, and if they did, they’re probably humming tiddely-pom while
standing around trying very hard not to watch like this is some major accident.

And apparently there was some other building trying to get its 16.8 seconds of fame in the background.

With apologies to Sports Illustrated, these pictures are from the leading off section of the 3-27-00 issue of Sports Illustrated.

Phillip Greenspun has surprised me again. I’ve read his pieces since 1995, and I’ve always been impressed with his combination of attitude, technical competence, and the good things that he has done for charities.

But I’m impressed again. He is putting a lot of money where his mouth is, and is starting an open source computer science university.

http://arsdigita.org/university/

Impressive faculty, good texts, and a lot of work in a year. If I had the time, I’d want to do it.

My connection issues have been resolved.
I now have at least 75K/sec download speed to my house (from akamai, peak dinner hours), and it looks like my peak rate is 1.5mbps, as reported from speakeasy.

***Mmmmmm bandwidth.

I ordered this service on 3-23, and now on 4-11 it is installed. Not bad for getting a new line installed without a normal landline phone to replace the one that flashcom (evil isp, avoid them) cut off instead of transfering.

Now I’ll see if Speakeasy’s service is the type that I pay for and forget about. If I don’t notice it, it’s doing its job. So far I’ve gotten 8 emails from them, including: one bill, one TOS, one DSL tips page, one welcome, and two notices that they’re taking the email server down for hardware upgrades. So I’m informed, not concerned, and I know that I won’t have 7 months of bills come at once. So far so good.

My dsl connection is down, in the aftermath of a disagreement between me and Flashcom over the meaning of acceptable downtime. I asked them for an ISP release for transfer to a different ISP, and they cancelled my line.

So updates are spotty while I have no internet access from home. Thankfully, I have 768k at work.

Recently hacked out: “XML-RPC via SMTP” and POP. It’s a comingling of initals that should have been kept seperate, a solution in search of a problem. And I think I found the appropriate problem, too. But more on that later.

*** The reasoning

XML-RPC is designed to send a mime formatted message from computer to computer via a http connection.

But, not everyone has connections that allow for hosting of a http server (such as ERROR (pike)) on their client machine. For some applications, encapsulating the xml-rpc message in a mail message can be an effective substitute.

There are some issues that need to be addressed. An email message is a potentially unreliable asychronous method of connection. This means that for any given email, not only may it not get to the addressee, the sender doesn’t necessarily know that there was an error. By contrast, a http connection either works or there is an immediate error.

On the other hand, there are a lot of mechanisims for eventually delivering email to its intended destination, including retries and non deterministic routing. You don’t need to have both ends of the connection up at the same time. This is helpful if your isp is not.

That and I shot my mouth off at manilapalooza that this wouldn’t be that hard to do.

*** The spec

The request is of the form:

X-Mailer: UserLand Frontier 6.2b1 (Macintosh OS) (mailServer v1.01 .698)
Mime-Version: 1.0
Date: Wed, 05 Apr 2000 18:53:58 -0700
To: rpcAddress@rpc.destination.machine
From: reply@address.caller.machine
Subject: rpc call to examples.getStateName
Content-Type: text/xml; charset=us-ascii
Message-Id: <20000406015305.D508F170044@mx.socialecology.com>
 
< ?xml version="1.0"?>

  examples.getStateName
  
      
       5
       
    
  

The essential portions of this are:

• To: addressed to a specified address. This is server and implementation dependent.
• From: The sender address. The sender may get a reply of the form shown below.
• Subject: Does not start with Re:
• Content Type: text/xml, to distinguish it from plaintext
• Body: this is straight from the rpc spec

A Sample Reply

 
X-Mailer: UserLand Frontier 6.2b1 (Macintosh OS) (mailServer v1.01 .698)
Mime-Version: 1.0
Date: Wed, 05 Apr 2000 18:52:48 -0700
To: reply@address.caller.machine
From: rpcAddress@rpc.destination.machine
Subject: Re: rpc call to examples.getStateName
Content-Type: text/xml; charset=us-ascii
Message-Id: <20000406015156.C7E0C170044@mx.socialecology.com> 

< ?xml version="1.0"?>
  
    
      
        California
      
    
  

*** The implementation

I have three scripts that implement this client – server setup.

• The smtp-rpc client, analogous to betty.rpc.client
• The server side server, implemented as a mailserver filter
• A client side server, implemented as a polling pop client using Alan German’s tcpcmd (version 2.1.2).

The server side server requires a working installation of my “mailserver”. The Client side server requires tcpcmd and a script to parse the headers. This is suitable for installation in ERROR (pike). (In fact, that’s where it was put together.)

All of the scripts are attached (in a table) to this message.

*** The Demo

All of the standard Userland examples are installed on an rpc-email server at om@budda.om.wiredfool.com. It will reply via email. Note that it will only process messages that are of content type text/xml.

*** The Caveats

This is early stage work. It does work on my machine, and it may not resemble any known specification. It builds heavily on Userland and tcpcmd code.

*** The Legal Stuff

There is no warranty. There is no patent. If you use this code, you’re obligated to do cool stuff with it. This is posted with the permission of my employer, “Socialecology”.

This is only a test message.

This is another line