[
Lists Home |
Date Index |
Thread Index
]
From: Paul Prescod [mailto:paul@prescod.net]
"Bullard, Claude L (Len)" wrote:
>>
>> Admittedly, I am using email very loosely here, a simplification
>> to mean no state is guaranteed, only expected. For some reason,
>> UDDI has methods that are very precise about expectations. I want
>> to know why they prefer that over REST because even to me, URIs
>> that identify known sources of typed information are easier.
>Dunno. You should ask them. ;)
You mean "They" aren't on XML-Dev? I thought everyone who was
anyone on "The Web" was on XML-Dev. What a let down. This web
services thing must not be very important if they don't even
know about XML. (poke at MS commercial).
>> It means that all I have to know to work from Google is www.google.com
>> and a possible search term.
>Right. Because web objects have an extremely simple interface in the OO
>sense and they always support GET if they support anything.
But also because that will always return a search page. The cognition
for the transaction is the search term and subsequent terms I submit
through that user interface.
>> ... After that, it is discovery-based if I have
>> the discipline to stay on track. However, unless I am very confident,
>> I deal with a response of lots of sources through which I must browse
>> to find the useful ones.
>Okay...I'm losing the thread here....
Precision. Discovery. Google is only as good as I am able to cognitively
recognize a precise term, a precise message to send which it will interpret
as a request. Otherwise, I get a few to a few thousand candidates back.
>> REST is. It doesn't send or expect state. It expects a representation.
>The representation is, in general, the representation of some *state*.
It's a document, packed in a URI or in the body, it's a document.
I'm not so sure Fielding did much more than the genCode and GML
guys did in recognizing that documents are how humans formally
communicate instructions (ok, gestures, speech acts, etc. but
these are bits on the wire with character encodings, so, docs).
>> How is that different from packing an XML file in a POST?
>There's nothing wrong with packing an XML file in a POST. XML is just a
>syntax for a message with some semantics.
It's a syntax until the right interpreter interprets it according to
the local semantics. URIness is just address space. Until it is
associated to a type (you like MIME), it is meaningless.
>You go wrong when you start to
>mismatch the semantics with the Web's natural data model, which is
>resources, URIs and representations (i.e. REST).
Ummmm... REST = Document. Otherwise we are just overloading
function names. If we do that, why not just use functions
(what UDDI does).
>Putting the parameters in the URI makes the query
>addressable.
It means I write the query's name next to its address on the
front of the envelope.
>> But not FTP. FTP let's me get and set directories, change file names, delete files,
>> and so on.
>HTTP also. DELETE deletes files. GET and PUT renames them (though there
>is an HTTP extension called MOVE which is an optimization). Getting and
>setting directories are primarily a convenience for interactive use.
Convenience may be at the heart of UDDI. Is there anything wrong
with convenience? Seems to me we accepted a lot of retrograde tech
to get the convenience of universal addressing. I don't particularly enjoy
stateless programming. It's a pain in the neck and not very fast. ;-)
>URIs are so much more flexible than the siloed naming schemes
>available in those protocols.
Flexible or just won based on a momentum that then hit a brick wall
of economics. We don't want to throw the baby out with the
bathwater, but saying "on The Web" sells exactly nothing these
days. In fact, it raises suspicious eyebrows (which is why
you are being put through this grilling). I agree that a universal
address space has advantages, but really, that is DNS for this
system. URIs are a way to put an application on the top of that
based on naming conventions and letting HTTP be the proxy master.
If MS had proposed that originally, most of you would still be
using FTP and WAIS. <offtopic>The brilliance of MS was realizing
their bad reputation was their strongest asset when it came
to directing the evolution of "The Web".</offtopic>
> ... In email, I send a request wrapped in
> an envelope to an address I know a priori because based on description or
> discovery, I have confidence the mail returned will contain a range of
> messages I expect, or I have to discover that address.
>Yes, but email is queued and thus almost never works at interactive
>speeds. And email almost always involves several intermediaries which
>sucks away even more speed. And as discussed above email has no
>"commands" (although SMTP *does* have commands).
That is a literal email client. The point is the problem of the
a priori agreements based on discovery. UDDI says that discovery
should be quick and precise, dedicated not to generalized search,
but to registries of business types with precise commands for
drilling down to get the stuff you want when you want it.
>> ... Google seems to me
>> to be a very inefficient way to conduct a series of business transactions.
>The search part of Google is not what REST cares about.
Very true. Discovery is what UDDI cares about. It is what the user
cares about. REST is another way to say, at this address
(if you know this address) is a document that tells you
the state of this resource at this time. UDDI is "in accordance with
the conditions we have agreed upon to this time". I need to understand
how all of the rest of that is done because an address
is not enough. In most cases, a name is not enough.
> Why do you think UDDI is designed the way it is presently as methods?
>Objects on the brain. I dunno. Why do you think UDDI was hyped as
>solving problems that only strong AI could solve?
I missed that bit. Hype is what we do to get a crowd.
After that, it is lecture or con. What I am slowly
and belatedly learning is that success in business is
a matter of wiring money to money. The rest is just
negotiation.
What I do know is that given the WSIO, powerful forces have
decided to go forward without REST. Maybe without food too.
I'd like to not see another dot. bomb because if these
particular forces get it wrong, it will be more than a few
hundred thousand misguided dot.commers on the street
this time.
To rephrase: even if it isn't RESTful, even if it isn't
"The Web" as some polity defines that rather abstract
incantation, will UDDI work 'well-enough', because
if it does, then the usual rubric of "running code
and rough consensus' is met. On with the wiring.
len
|
