Archive of UserLand's first discussion group, started October 5, 1998.

Omitting type tags; was Re: New tweaks for XML-RPC?

Author:Bob Atkinson
Posted:1/29/1999; 11:40:03 AM
Topic:New tweaks for XML-RPC?
Msg #:2572 (In response to 2561)
Prev/Next:2571 / 2573

WRT the type-representation issues:

Why not simply eliminate the type-tags altogether?


 3
 this is a string param

instead of


 3
 this is a string param

In its fullness, this change would percolate through arrays & structs, but for the moment, let me just stick to the basic, scalar types for motivation. I'll followup with the other info in later responses.

(Aside: even better, I think, would be


 3
 this is a string param

but that requires rethinking how to pass the names of named-parameters.)

A few observations motivate my suggestion, among them:

(*) It's simpler, in that the packets become easier to read and to grok.

(*) If you're basically going to reduce the scalar types to just , why bother saying that data type each time (I'd still keep element tags for structured types, like & .)

(*) My experience is that servers that receive calls have enough intrinsic knowledge so as to be able to coerce incoming data into the type that's internally needed and expected. So this type informaton doesn't have to actually be transmitted on the wire.

(*) Not sending type info on the wire is the approach taken by traditional RPC systems such as DCE's NDR, thus providing an example that this idea is at least not completely off the wall.

(*) If you omit meta data on the wire, then it becomes feasible to build a XML-RPC server infrastructure that can easily service BOTH XML-RPC calls AND CGI calls. For example, a GET to

http://www.stockquoteserver.com/stockQuote/GetLastTradePrice?Symbol=DIS

might map into an equivalent XML-RPC invocation

POST /stockQuote HTTP/1.0
Host: www.stockquoteserver.com
...

  GetLastTradePrice
  
     Symbol
     DIS
  

The key point here is that an incoming CGI invocation doesn't have type info, so it'd get hard to map it to a XML-RPC that required same.

I think that extending the reach of XML-RPC to the CGI syntax in this manner is quite interesting indeed. It allows an XML-RPC server to serve a much broader range of client engines than it could previously. You as Joe-web-app-developer just get that much more power by focussing your sever-side development efforts under a XML-RPC engine who can then handle the breadth of clients all automatically for you. Such engines are thus that much more useful in the world.

Just some thoughts....




There are responses to this message:


This page was archived on 6/13/2001; 4:47:39 PM.

© Copyright 1998-2001 UserLand Software, Inc.