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

Re: WDDX Annotated DTD

Author:joubin
Posted:1/18/1999; 12:06:51 PM
Topic:WDDX Annotated DTD
Msg #:2211 (In response to 2210)
Prev/Next:2210 / 2212

I am not sure I understand the installed base issue. Note that I am NOT necessarily advocating this change, but I would like to know if I missing something about XML-RPC mechanism, since I am using it myself.

The issues:

1) First there is the issue of the betty responders: On my root, there are: 

	admin
	CGI
	default
	echo
	helloWorld
	RPC2
	server
	websiteFramework

Couldn't a new responder (e.g. RPC_XE) be added through the net-update feature of Frontier 5?

2) Then there is the issue of clients using XML-RPC(2).

a - On non-Frontier systems (i.e. Java RPC client, Perl, etc.) the code would have to change, but this would (rather, should) only be in the body of the object preparing the HTTP request -- i.e. the interfaces to these clients will be unchanged.

b - On Frontier systems, the standard way of making xml-rpc calls is through system.verbs.builtins.betty.rpc.client which has this interface:

   on client (                          
   rpcServer="localhost",               
   rpcPort=user.inetd.config.http.port, 
   procedureName="",                    
   adrparamlist=nil,                    
   fldebug=false,                       
   ticksToTimeOut=60*30,                
   flShowMessages=true)

Now, unless frontier users have been building XML-RPC applications which DO NOT use the above script (are they? and why would they?) any changes to 'client' would be transparent to any 3rd party frontier application which utilizes XML-RPC through this interface. I.e. a one-time update of system.verbs.builtins.betty.rpc.client through network-update feature should not affect the installed base of these applications.

If the frontier root is NOT updated, system.verbs.builtins.betty.rpc.client will be making "RPC2" calls. If it is, system.verbs.builtins.betty.rpc.client would be making "RPC_XE" calls.

The RPC(2) client itself contains the following line:

   s = tcp.httpClient (             
	   method:"POST",               
	   server:rpcServer,            
	   port:rpcPort,                
	   path:"/RPC2",                
	   data:xmltext,                
	   datatype:"text/xml",          
	   debug:fldebug,               
	   timeOutTicks:ticksToTimeOut, 
	   flMessages:flShowMessages)

where "RPC2" is the default value for the 'path' parameter. Changing this (and updating the installed base to replace system.verbs.builtins.betty.rpc.client through the network-update feature would also be transparent.

--

Obviously the assumption here is that developers/users using XML-PRC features are 'power users' and presumabely are paying attention to notices by UserLand regarding important root updates. And if they are, it is a trivial matter to update their roots to include RPC_XE (and related changes) to their root.

Even at an extreme case where an updated XML-RPC client is sending RPC_XE POSTS to a server, any error from server saying, in effect, "say what?" could trigger a re-send using good old RPC2 post (which still available to the updated client!).

So the real installed base issues (imho) are:

1 - non-frontier XML-RPC clients, which would entail a one-time patch by the developers of these clients (which I assume are literally a handful?), and

2- Frontier XML-RPC applications which for some reason ARE NOT USING system.verbs.builtins.betty.rpc.client.



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

© Copyright 1998-2001 UserLand Software, Inc.