Opening Lines of Communication
Posted 1 May 2002 at 12:21 UTC by rubys
Take a simple query. Direct it at a resource identified via a URL.
Pass it a few query parameters. As an architect, I can grok this
concept. Now there may be a number of isomorphic, 1-to-1 and onto ways
of representing these parameters - for example, concatenating the
parameters on the resource identifier, or encoding the parameters
separate from the resource. But be careful, if you chose one of to
separate the parameters, you will be labeled a "client-server" person
who "can't bear to represent their information separately from their
plans for processing it."
At least, that's the impression I get reading Simon's latest diary entry.
Let's seek some common ground. It may very well be true that some
or even most SOAP as practiced today is not RESTful. But it would be a
falacious to deduce from this statement that all SOAP usage is not
RESTful.
Most of all, lets open the lines of communication
Uh, Sam?, posted 1 May 2002 at 13:48 UTC by simonstl »
(Master)
I don't believe I labeled anyone the way you describe. I was telling a
story about the Web with a good dose of (I think much needed) historical
perspective.
You might want to take a look at the Web Services Discussion
Worth Watching Story that's four down from this one to explore
communication so far - it's been pretty interesting.
I strongly doubt that responding to my diary this way is a wise method
of seeking common ground.
One evil minded person
on my site
create a
URL with this string "badvogato.org/proj/%07/". Apparently, this special
character "%07" generates an oscillated disturbance on a function unknown to the
troubleshooting engineer.
Take a free guess: how to fix the bug? And what is this bug?
If the disturbance you are talking about is the blinking of the page,
it has nothing to do with %07 project, but is related to
"<blink>Prophet" project. When you go to the project page, only
the title blinks, because the <blink> is "reset" </h2>. In your
list of projects, the <blink> isn't closed...
Solution: HTTP encode the projects name special charcaters like < and >
I am currently using Pliant HTTP server and dynamic pages.
Using it, it is possible to pass parameters in a fully non visible way
by mean of "virtual tree": for instance, URL
http://myhost/mysample/prime/by5cols/100.html will execute the code
in the page /mysample/prime/virtual_tree.page with a virtual path
"/by5cols/100.html". Once parsed, my page actually prints the primes
up to 100 (last parameter) in a table with 5 columns (first parameter).
Similarly, file browser, forum browser, data browser (database access),
type browser (scanning of compiler type definition) are dynamic and
use a similar scheme for URL encoding, which gives no hint on the fact
pages are dynamic and get parameters from the end of their URL.
No, pom. blinking is my site's trademark. What bothers me is /proj/%07/
turned a dynamic page recentproj.html into a static one. It seems
/proj/%07/ brakes the link in a function which re-writes
"http://badvogato.org/recentproj.html" from
"http://badvogato.org/proj/". Due to that disturbance, the dynamic
property of Evil Plans on the frontpage no longer functions. You can see
that quite clear. After
Scientology plan, all new evil plans never get on the frontpage.
I believe it is Darwinism at work. By natural selection of evilminds,
Badvo is evolving into mold of his
creator's image . On this National Day of Prayer, let's pray all
henchman on my site can continue boggling their evil plans without the
curse of frontpage flames while TRUE noble minds like you and I can tend our own
business seriously.
"http://badvogato.org/proj/This%20Is%20a%20Theory" 1877 echoing
replies washed away the earlier fun part of those replies
Click
at your own risk
I guess I've just formed some sort of opinion in this debate after seeing
pom's reply. :-(
I feel that thinking in terms of "queries" and "parameters" is somewhat
backwards. A client shouldn't need to know, for example, whether the projects page of this fair site comes from a static file, a
database query, or some other process. In short, everything should be
treated as a resource.
(Seen in this light, it'll seem that the CGI query string format is also
a bit of a hack...)