Gregg,
On Apr 10, 2006, at 11:44 PM, Gregg Wonderly wrote:
> Mark Baker wrote:
>> On 4/7/06, Gregg Wonderly <[EMAIL PROTECTED]> wrote:
>>> I did say that HTTP was really immaterial. Other protocols can
>>> provide the same
>>> semantic features as HTTP.
>>
>> Such as?
>>
I still wonder....what are the protocols "that privide the same
semantic features as HTTP"?
Jan
>> FTP's probably the most similar protocol we have to HTTP, but it's
>> missing the semantic equivalent of POST. IMAP too. NNTP has POST,
>> but no equivalent of PUT.
>>
>> HTTP is special amoungst application protocols because it's the only
>> one that knows URIs.
>
> These are all inter-dependencies. You are taking advantage of URIs
> as a
> namespace by using HTTP. Because you've got HTTP everywhere you're
> dependent on
> having URIs.
>
> Mark, I know that most all of your argument and emphasis is based
> on the fact
> that HTTP exists as a spec, HTTP servers exist as a platform, and
> URI handling
> is available on most software development platforms. That is all
> true and
> beneficial. With HTTP the "transport" and the "content", were tied
> together
> because of the influence of other protocols, such as gopher, with a
> document
> focus. So, now we have the view that large scale transfers are
> "better" than
> small scale exchanges, because it is easier to get a document with
> HTTP than do
> do many other things that have been used in the passed for client
> server
> computing. The problem is that large scale exchanges expose large
> scale
> implementation details when sometimes those dependencies (document
> content/structure) should not be revealed, or used for many
> different reasons.
> But, that's a whole other argument.
>
> I'm specifically focused on the issue of worrying about the
> "specific" protocol
> as the premise for your software design, instead of the "semantics"
> of delivery
> of data in both directions. HTTP should be used as an enabler not
> as a premise.
> Because there is data available via HTTP, and there are very
> useful sources at
> that, many people write software hardwired to HTTP and the content
> delivered,
> and then are frustrated when the document changes, the URI changes,
> or something
> else hardwired, and unspecified in the "contract" changes.
>
> By going through rigorous software design, and abstracting the
> protocol and
> invocation layer away from the software system being designed, you
> force
> yourself to confront all of the dependencies on the semantics and
> either provide
> an abstraction or an argument against/for the dependency on the
> implementation
> details.
>
> But, perhaps the throw away code crowd has a little more ability to
> accept the
> fragile nature of this than I do.
>
> Gregg Wonderly
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
