xml-rpc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Hoegg <rho...@isisnetworks.net>
Subject Re: recent patches
Date Fri, 13 Sep 2002 18:17:13 GMT
arh14@cornell.edu wrote:

>Andrew, I must not be making myself clear, and the blurry definition of a 
>"context" object is confusing things.
>
>My whole purpose of adding the ability to read and write headers, is so 
>the client can _propagate contextual information to the server_ which are 
>not part of the rpc arguments, and are potentially handled behind the 
>scenes on the server side (or perhaps explicitly through a ContextHandler 
>as you proposed).  The whole point is to propagate contextual information 
>from the client to the server, so of course being able to set said 
>information on the client is necessary.
>
>Here is a simple example: perhaps I want to record, oh, the Operating 
>System of each client.  The client then needs the ability to send the 
>operating system as a contextual information to every call it makes, 
>along side the call, behind the scenes.  Of course, the alternative is to 
>sprinkle an extra parameter (or more) in every single call that could 
>ever possibly be made.  The point of contextual information (at least how I am using it,
and how I think it is used in most RPC terminology) is to pass along some meta-information
alongside a call that is handled seperately (for instance it may be logged in a database on
the server side regardles of what call was actually made).  Otherwise I can't find the idea
of server-side-only contextual information very useful.  The ability to pass arbitrary contextual
information is IMHO mandatory when you are integrating with disparate systems.
>
Hi.  My service provider has had an XML-RPC API to their application for 
over a year now, and they have had to solve the same problem.  They want 
to be able to identify 1) the business client that is accessing the app, 
2) the username/password credentials of the user within this client, 3) 
session ID, and 4) the version of the API the client is requesting.  In 
addition, they support some "more meta" information (is that a word? :)) 
such as HTTP compression settings, SSL, etc.

Their solution was to do exactly what you mentioned: requiring this 
information as a struct in each XML-RPC request.  They also use a cookie 
(redundantly) to set the session ID.

The problem with trying to embed "meta-information" is that either
A) It has to be a part of the XML-RPC request, as above, or
B) it is not a part of the XML-RPC request.  This could be cookies, or 
other transport protocol features such as POST parameters or some such.

My objection to B is that it is necessarily not covered in the XML-RPC 
spec, causing an interoperability problem.  There are stable software 
libraries out there right now doing MIME-RPC, for instance, using the 
XML-RPC spec but switching out HTTP for MIME.  The more implementations 
decide to bend the spec in different ways, the less useful the spec becomes.

Your example of the client operating system is a perfect example.  IMHO 
the way to do it is to submit an XML-RPC request defined by the 
application to authenticate and get a session ID.  This initial request 
can contain such information, and future requests can contain the 
session ID.

Ryan Hoegg
ISIS Networks


Mime
View raw message