25 Apr 2002

Thu, 25 Apr 2002

Huge Thanks To Joe Gregorio At BitWorking

I just wanted to send out a huge thank you to Joe Gregorio at BitWorking. I came across Joe's CSS theme for Radio this evening and it answered my prayers for an easy to install, flexible, light-weight system for rendering my blog. Awesome work Joe! Don't let Joe's comment make you think it's too difficult to install. I'm about as novice as they come with regard to Radio and CSS and HTML but I had no difficulty whatsoever getting the system running. The only blip I came across in Joe's instructions was that the javascript.html file was not included in the zip and so I wasn't sure whether it was safe to copy off the site being that it was post-rendering. So I left this link pointing at Joe's site knowing that I'd figure it out eventually.


Here are the estimated download times for my site after the switch to Joe's CSS theme. From Dr. Watson:














































Object type Number Size in bytes
Estimated download times (seconds)

14.4

28.8

33.6

56k

128K

T1
   HTML 1 18217 13.29 7.29 6.07 5.20 2.28 0.91
   Images 6 2993 2.18 1.20 1.00 0.86 0.37 0.15
Total 7 21210 15.47 8.48 7.07 6.06 2.65 1.06


That's quick! Extremely quick. And it still looks great. I'm psyched!

Posted at: 22:52 | permalink

Rebutting Paul Prescod

Paul Prescod: Google's Gaffe. "I take the SOAP-ifying of Google as a sign that the web services hype has now reached overdrive."  [scripting.com]


Quoting Paul's article on xml.com:



But all of these advantages are like the tiny diamonds that ring the big rock. The most important advantage is that an HTTP version is part of the Web rather than merely being behind it. This point is subtle but the most central. A piece of information is on the Web if it has a URI, accessible through a Web protocol or is embedded in an accessible document. When Google exposes its service through SOAP, it is behind the Web because the object with the web URI is the SOAP component ("endpoint"), not the actual query results. I need to go through the component to get to the data, like making a phone call through an operator instead of dialing direct. But in the XML/HTTP/URI way of thinking, every possible query result has its own URI and thus is a first-class web data object.


I hate to burst Paul's bubble, but the use of SOAP does not preclude the use of HTTP GET/POST bindings. A particular toolkit may not support this idiom, but Electric's Glue does. We use this method quite often to define services that return a string that is merely decorated in whatever fashion the client desires; in this case, HTML.


Quoting Electric's Documentation (via Google's cache):


GET POST Bindings


GLUE includes support for HTTP GET/POST web service bindings. To invoke a web service using an HTTP GET, use the syntax endpoint/method?arg1=value1&arg2=value2. To try out this feature, run the examples.publish.Publish1 server and then type the following URL into your web browser.






http://localhost:8004/glue/urn:exchange/getRate?country1=usa&country2=japan


You will see the return result displayed in your browser window. If you invoke a web service in this manner using an HTTP POST, all parameters of the form $x are automatically replaced with their corresponding actual values from the POST form.


I agree with Dave on this one. REST advocates can continue to battle. I've been using XML-RPC and SOAP since they were first available and I have produced demonstrable GUI applications in a variety of languages with usable performance characteristics and that's good enough for me.

Posted at: 07:20 | permalink