[exprla-devel] Re: [XPL] XML/Web infrastructure

[reid_spencer <ras...@re...>]

--- In xpl-dev@y..., Lucas Gonze <lucas@g...> wrote:
re: paradigms shifting away from procedural programming and http
limitations as an rpc transport -

I believe that the move underway to have everything be a server
_and_ client leads basically to an asynchronous way of thinking
where procedure calls have 0, 1 or more results.  the first major
problem with http is that it is hopelessly tied to sychronous
call & response.

the second major problem is that it is tied to html as a content
type.  as messages pass from node to node the content and
transport may change.  http 1.1 specifies specific rules for how
browsers, proxies and servers interact. they are explicitly
different animals.  this approach works badly enough for html in
a browser.  For reliable procedure calling it is a flawed
approach.

For example, a proxy is supposed to convert chunked encoding to
non-chunked.  This is helpful to a client that is a browser.  But
if the actual client is another proxy then this will cause
problems.  If the data is streamed it can cause serious problems.

Brooklyn is hot today.  totally hot.  Apologies if this writing
reflects the fact that I am moving (and thinking) as slowly as
possible to keep the sweating to a minimum.

- Lucas

> We are shifting paradigms here, and as a general rule of thumb,
> as one paradigm becomes ascendant another becomes obsolete.
> It's my personal conviction that the paradigm being shifted is
> not HTML -- although that will in fact be subsumed by the
> technology over time. Rather the paradigm is procedural
> programming itself. As I see it, over time VB, Java, and even
> (gasp) C++ will take on increasingly XML like characteristics,
> to the point where eventually these languages largely disappear
> as independent entities. That is not necessarily to say that
> they will be cast in an XML description (though that may happen
> in some cases). Rather, the mechanisms for handling procedural
> languages will grow out of the hydra-like head of XML, with XML
> itself likely to evolve in the process.
> 
> > I don't think XML-RPC and SOAP use the "HTTP protocol
> incorrectly", though
> > I certainly think it's worth considering more efficient
> transfer protocols
> > with clearer security.
> My biggest problems with any type of XML based RPC is that,
> while you can write very efficient RPC code that effectively
> keeps most of the interaction in a periodic request from a
> client to a server to send in a larger stream of data (and this
> use I don't have problems with at all), it can also be used to
> control component interactions on the server one command at a
> time.  RPCs have typically been complex things to write,
> involving skills that were sufficiently specialized that there
> was a prerequisite understanding of how best to optimize the
> RPCs service. However, by making RPCs much simpler, it lowers
> the bar on the skills necessary to create such RPCs, which in
> turn means that you'll see more people use XML-RPCs to handle
> routine component control commands that should typically be
> handled within a compiled (or at least protected) control.
> Thus I have this disturbing visions of lots of RPCs basically
> performing incremental procedural coding between environments
> using XML as the basis, which is the worst possible way of
> designing such systems.
> 
> My second concern with RPCs is that they are running over http,
> typically through port 80. Firewalls exist for a purpose -- to
> keep critical subcomponents from being programmed illicitly.
> SOAP especially is designed (and this has been a common thread
> coming from a number of different vendors) to bypass the
> firewalls. Thus by explicit admission, SOAP in particular
> serves as a means of circumventing security measures put in
> place by sys admins in the first place.
> 
> These were the specific objection that I had when I said that
> XML-RPCs used the HTTP protocol incorrectly. The syntactic use
> of such techniques is undoubtedly correct, though they do rely
> on extensions to the protocol, but so do many other things.  It
> is more in the usage of SOAP that I see a conflict with the
> design goals of HTTP, and the biggest danger from it.  I should
> point out that I do see the obvious benefits of incorporating
> SOAP -- it is a powerful technology; it is however this exact
> power that worries me.
> 
> > I think it's time to consider changing the Internet to make
> better use of
> > XML and to simplify implementing the possibilities XML opens
> up.  It's not
> > yet time to throw everything out and start over, but I'm glad
> to hear that
> > people are willing to at least consider the possibility of a
> transition.
> I'm not questioning the sentiment (which I personally agree
> with), but the feasibility.  The Internet evolved -- at no
> point was there a single conscious decision for it to appear in
> the form that it did; rather, as different people contributed
> different facets to this communication protocol and all the
> technologies overlaying it, the Internet lurched and lunged
> through different embodiments of itself.  XML as a language for
> creating the semantic web is laudible but far too late; as a
> consequence, the best approach may very well be to introduce a
> new meme into the existing infrastructure that would make it
> evolve toward the newer requiremenets. This is a very
> counterintutive notion, that one should grow or evolve the web,
> but I suspect that it may be the only way that we can
> effectively integrate this new paradigm into the systems at
> hand.
> 
> BTW, it's late, I've been chasing kids around all day, and I'm
> probably not making a lot of sense at the moment.
> 
> -  Kurt Cagle
> ----- Original Message -----
> From: "Simon St.Laurent" <simonstl@s...>
> To: <xpl@e...>
> Sent: Saturday, June 24, 2000 9:29 AM
> Subject: [XPL] XML/Web infrastructure
> 
> > I'm going to reply to various bits, and hope this doesn't get
> too confusing.
> >
> > Richard Hein wrote:
> > >www.xml.com has an articles about some things we need to be
> > >informed about,
> > > including the foundational infrastructure of the 'net and
> how XML
> > >makes too
> > > much of a demand on the current infrastructure,
> >
> > I'm not certain that XML makes 'too much of a demand', but it
> certainly
> > makes demands and opens new possibilities.  I tend to enjoy
> the
> > 'disruptions' XML causes.
> >
> > Kurt Cagle wrote:
> > >I just spent three days closeted with Simon St. Laurent, who
> wrote the
> > >article, and while I agree with him in part, I would also
> keep in mind that
> > >he represents just one side of this issue.
> >
> > Kurt's completely right that there are _many_ sides to all of
> these issues.
> >  I wouldn't have written the article if it hadn't been for
> the strong
> > opposition some of those opinions have generated.  I'd like
> to see XML
> > carry on disrupting things, but not everyone is happy about
> that.
> >
> > Kurt wrote:
> > >I do agree
> > >with Simon with regard to the issue of SOAP and XML-RPC, and
> I have made me
> > >feelings known about that in the VBXML board -- we are
> utilizing the HTTP
> > >protocol incorrectly, placing too many demands upon it to
> efficiently handle
> > >the use of the network as a common interchange medium for
> messagess. It also
> > >gives me more than a little pause about both security
> concerns and
> > >architecure.
> >
> > I don't think XML-RPC and SOAP use the "HTTP protocol
> incorrectly", though
> > I certainly think it's worth considering more efficient
> transfer protocols
> > with clearer security.
> >
> > Then Richard wrote:
> > >Kurt says that he
> > >disagrees with Simon St. Laurent, who wrote an article on
> the problems with
> > >the current infrastructure on http://www.xml.com in the
> sense that it may be
> > >too late to change a lot of it now.  I don't really know
> what to think about
> > >that, but I wonder because it only took a few years for the
> internet to grow
> > >out of obscurity into this huge thing, so why would it be so
> bad to change
> > >it somewhat for XML?
> >
> > I think it's time to consider changing the Internet to make
> better use of
> > XML and to simplify implementing the possibilities XML opens
> up.  It's not
> > yet time to throw everything out and start over, but I'm glad
> to hear that
> > people are willing to at least consider the possibility of a
> transition.
--- End forwarded message ---