Bob La Quey wrote:
Then the underlying frame work would parse all that (using regex for
the variables) and map it to a function. The function might look
something like transact(from, to, assigns=defaults) or some such.
Here the arguments come from the regex and the defaults came from
Sally's configuration file when to=Sally. The function, transact()
would be written to manipulate Python objects.
OK, that's cool.
In Django, and some other web frameworks, no thought or knowledge of
SQL on the part of the application programmer is needed.
I guess if you don't consider actually manipulating the database to be
part of the framework, sure.
Why is the URL better than a stored procedure call?
Or the URI that represents "Lock my mailbox against writing until I'm done
reading my mail and I have decided what to delete and what to keep." Don't
forget to unlock it if, for some reason, I finish without unlocking it.
Sort of the same as above. I will leave it for others to develop the details.
Sorry. I'm not sure I follow how you have a stateless application server
that can lock a file only while your process is alive.
A key issue for this sort of thing though and an area where REST (an
HTTP) provides no solution is WATCH/NOTIFY support. See
http://wisdomofganesh.blogspot.com/2008/01/roy-fieldings-fundamental-omission.html
Yes, I realized after I walked away from the computer that I'd forgotten
to include that case.
"After Fielding's work, the Web began to be seen as something
consciously designed and built according to well thought-out
principles." Heh. Post-hoc description doesn't imply anything like this
was "consciously designed". I mean, a thesis written 10 years and two
versions of HTTP and a dozen versions of HTML later doesn't really say a
whole lot about what the architectural design was. It all evolved. Each
bit of HTTP after the first release was put in there to solve a problem
people were having with REST in the first place. The whole bit of SSL
maintaining session state between connections, the whole bit of HTTP/1.1
letting you leave the connection open, the whole bit of basic
authentication headers... these were all things put into HTTP to *solve*
the problems that the REST model caused, none of which were necessary in
SMTP or FTP for example.
BTW, check out the BEEP protocol if you want to see a less-limited
version of interactions that still has a lot of the benefits of HTTP.
And do read the comments.
Heh. "I can't name a successful, scalable, multi-organizational software
system that truly works as an full-stack peer-to-peer based
architecture." Yeah, because, you know, the traffic from email is still
quite a bit larger than the traffic from HTTP. And the traffic from PSTS
is still probably an order of magnitude larger than the traffic from the
internet. And of course IP isn't a successful, scalable,
multi-organizational software system that works as a full-stack
peer-to-peer based architecture, and neither is OSI.
Or the URI that represents my ssh session to the server over there.
Hey that is a good one. It is late. I will tackle that one day after
tomorrow, cause tomorrow I go to San Diego and my day is shot. I do
think I can do that :) We shall see.
I'm sure you can come up with a URI. But keep in mind that you get one
request to a stateless server and one response, to represent your SSL
session. :-) I'll be interested in seeing that.
No, really, not everything is REST, and not everything can be represented as
one independent round trip to a server and back. There really is state in
the world. :-)
Oh, I do agree there is state. I just think there is not nearly as
much of it as you seem to think.
I think that depends on how much state you put into the session. Is my
shopping cart at Amazon state? Is my searching history at google state?
> Also I am getting a lot of mileage
out of thinking of some state, for instance session, as simply
constucting an instance of a server, then for the duration of the
instance that server is stateless.
I think the point of the REST thinking is that the server should be able
to handle as many different clients as it needs to. You should be able
to have every request coming from a different client and still have it
work.
--
Darren New / San Diego, CA, USA (PST)
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
