News and commentary from the cross-platform scripting community.
Mail Starting 1/13/98
In my analysis of your XML + RPC proposal, it seems that your current proposal is not supported by the HTTP/1.0 specification from RFC1945. Fortunately, your proposal can be corrected fairly simply.
From: email@example.com (John Saxton);
Sent at Thu, 15 Jan 98 12:21:22 -0800;
Current XML + RPC proposal might not work with HTTP/1.0 (?)
Let me say at this point that I'm not completely confident in my understanding of your proposal, so I value any feedback or clarification you can provide if I've misunderstood something.
According to the HTTP/1.0 spec in RFC1945, two pairs of CRLF's in a row signifies the end of the HTTP request headers. If the HTTP method was a "GET" as you describe rather than a "POST", then the HTTP/1.0 spec offers no guidance on what to do with the data after the two CRLF's. If the spec doesn't cover it, you might find that behavior in this situation will vary greatly from one HTTP server to another. The most common problems I foresee would be due to the server not expecting more data and either (a) entering an error state, returning an error to the browser, and closing the connection, or (b) passing just the "GET" line to the XML gateway process, and dropping the unexpected XML data "on the floor".
Luckily, the fix is simple to conceive. The standard HTTP/1.0 way to do what you propose (i.e. send data in an HTTP request but after the request headers) is to change your method to "POST", add the "Content-Length" and "Content-Type" headers, and send your XML data in a MIME-compliant way, very much like HTML form data or file upload data is sent.
My understanding of the HTTP protocol is that the GET method isn't supposed to send any data to the server.
From: firstname.lastname@example.org (Adam Turoff);
Sent at Thu, 15 Jan 1998 12:36:26 -0500;
There's an infrequently used and mostly misunderstood PUT method that can be used to put files onto the server. I think that Navigator Gold and Communicator use this to publish files onto a (Netscape) Server.
Of course, there's always the POST method, which is widely used and very well understood, and is typically used for sending data to the server (unlike the GET method).
My gut feeling is that modifying a web server to accept and pass on data for a GET request is rather non-standard and a bad way to move forward, all things considered. It would be easier, standard and more easily accepted to run off of a POST request with a different preamble. That way, what you're left with is an ORB (yet another TLA) that can handle your RPC. It won't be platform specific, language specific or server specific. And, on top of that, you can have multiple ORBs on a single server or a series of servers that can respond to multiple types of requests (/admin/gateway.cgi, /public/gateway.cgi, /dns/gateway.cgi, etc.).
What are you left with? A level playing field that ignores a decade of complexity where each programmer/vendor/idea can be judged on it's own merits. (Yeah, so I'm a bit utopian this morning...)
Was speaking with someone from the Four Seasons in Austin today, and she told me that the hotel was going to have shared T1 in all the rooms by year's end (actually, I think she said by April, but don't want to put words in her mouth), along with wireless ethernet around the building for people roving with their laptops. Right now they just (just!) have two POTS lines to every room.
From: email@example.com (Adam Rice);
Sent at Wed, 14 Jan 1998 19:31:52 -0600;
T1 in hotel rooms: Four Seasons Austin
1) You can't (legally) put a body in an HTTP "GET" request. You can in certain other methods.
From: firstname.lastname@example.org (Alex Hopmann);
Sent at Wed, 14 Jan 1998 14:54:28 -0800;
Comments on HTTP RPC
2) "POST" is a well known "black box" method. It can mean anything. This is good & bad. The good thing is that it is easy to use it to build any random application. The bad thing is that you can't tell what it means unless you are that application. I predict that firewalls are going to start restricting POST since they can't tell what it means.
3) To build this sort of architecture, dealing with unique namespaces, etc, becomes really important. When I say execute "foo", is that the same thing that you mean by foo? This isn't a problem if you are doing RPC all between products made by the same person, but if you are dealing with a multivendor environment, you need a solution. The XML namespace solution (and the general use of URLs for unique identifiers) helps alot.
From: email@example.com (Laurence Rozier);
Sent at Wed, 14 Jan 1998 10:13:24 -0800;
By default JOE saves to disk. This was fine for a file containing lots of objects, but really sucks for finer grained access. The ODB can take care of that and more. This is just the tip of the proverbial iceberg.
Please take a look a what JOE is about at:
I'm out for the morning, but will get more specifics to you later today about what this atomic puppy can become when it grows up.[hint: it will bark in XML!]
Knee Deep and still diggin!
FIY, the bucking bronco is already taken; O'Reilly used it on its Linux books. But since bison is the name of a moderately well-known Unix tool, it doesn't quite work for me as a Frontier O'Reilly cover either. :)
From: firstname.lastname@example.org (Charles Kerr);
Sent at Tue, 13 Jan 1998 15:10:47 -0600;
It has been my experience that most hotels do not have a telecomm engineer on staff and generally do not even have one they can call when they need one. Most of the communications networks I have seen in hotels are significantly under engineered. For example many of the CATV systems use "home" quality components instead of "commercial" grade components. In most hotels, the architect provides only one small wire duct to each guest room and the interfloor ducts are very small. In addition, the telecom room (closet) on each floor barely has enough room to cross-connect the room drops to the riser cable - most have no room for hubs or routers. When the rooms are wired, most hotels go the cheap route and use 2 pair wire only.
From: email@example.com (Jim Gendreau);
Sent at Tue, 13 Jan 1998 11:50:00 -0800;
Why Hotels don't have Internet Access
Based on these conditions, most hotels would have to completely rewire the entire building, build larger telecom rooms on each floor - they might have to eliminate a guest room on each floor to get the space, and then work with an ISP to get a common internet connection to the site. The labor to rewire a building is very expensive.
The bottom line is most hotels do not have the existing infrastructure to build internet service on and do not have the expertise to add the capability.
BTW - cable modems are not a viable option since the cable TV plant in most hotels is so substandard.
The good news is that some hotels used a far sighted telecom engineer to set up the site and are easily capable of providing internet service (these tend to be the hotels that have a lot of other high-tech services) and a few hotels are making the investment to upgrade their infrastructure to provide these services (these tend to be expensive full-service hotels that have the money to make the investment).
The best solution is to avoid hotels that don't have the services you want (and tell them why, often) and use hotels that have the services ( and tell all your friends). It would be helpful if someone (Mobile Computing Magazine maybe?) would put togethor a web site listing the hotels that are internet friendly.
Good luck with your quest.
Lightning Pinetree Associates
Please don't use my name if you post anything from this message.
Sent at Tue, 13 Jan 98 10:29:18 -0800;
Ethernet in Hotel Room
IBM has a private hotel in Palisades, NY. They use it for meetings. I was there in June of 1996. My room had a PC with a VERY fast internet connection... the fastest I've ever used. I would have to assume that it was on an Ethernet LAN although I didn't look.
I stayed at the Hayes Conference Center in San Jose last July for a company off-site. The rooms had two phone lines--one of which could be used for a modem--and an ethernet tap. Unfortunately, none of the staff at the front desk knew how to connect to it or what the IP, netmask, etc settings were. Tantalizing and disappointing.
From: pfterry@Cadence.COM (Fred Terry);
Sent at Tue, 13 Jan 1998 11:55:18 -0600;
ethernet connections in hotels
|This page was last built on Tuesday, April 7, 1998 at 7:01:11 PM, with Frontier version 5.0.1. Mail to: firstname.lastname@example.org. © copyright 1997-98 UserLand Software.|