So the last release I made of RPC::XML was announced as the first beta-quality release of the package. Which is to say, I felt that the code was at a point of maturity wherein the likelihood of major API changes was approaching zero. I don't take lightly the transition from alpha to beta-- Perl-RPM is still alpha after much more time spent in development than I've devoted to RPC::XML.
But sometimes, the really useful ideas for simplification of the API (or even for general usability, for that matter) don't come along on a convenient developmental schedule. Which is why I'm considering the very real possibility that the next release, whatever number I assign it, will introduce some difficult changes from the point of view of anyone currently making heavy real-world use of the package. And I wouldn't be considering these changes, but for the fact that they are sound concepts, things I have dwelt upon for many days and looked at from many angles. They will make for a better package. But there will be a teething problem with them, because I just presented to the community-at-large what I claimed to be a stable API.
Of course, I am going to do it, and release likely sometime around Friday or so, depending on other factors. It's the right thing to do, from standpoints of design and usability. I just wish I'd thought of these changes three weeks ago.
--rjray
- Rename the RPC::XML::Method class as RPC::XML::Procedure.
- Create a new RPC::XML::Method that is an empty sub-class of RPC::XML::Procedure.
- Integrate this into the server classes by creating add_procedure*() analogs to the method-adding subroutines.
- Add support for procedures to the XPL dialect and the make_method tool.
- From this point, "procedures" and "methods" are distinguished from each other as follows: Methods continue to function exactly as they have thus far, with the first argument in their list of parameters being the calling object referent. Procedures, on the other hand, will not get this parameter (and as a result, not have access to the information and additional methods it provides).
- The dispatch loop in RPC::XML::Server may then use an ISA test on the object in question to decide whether to include the extra parameter. Were RPC::XML::Procedure an empty subclass of RPC::XML::Method rather than this new configuration, there would have to be explicit type-comparison tests. Besides, in this case a method is a specialized form of a procedure, not vice-versa.
- Look at issues around the package namespace that methods/procedures are called in, and make certain there is documentable sanity in this.
- Add the fault- and error-handler capacities to the client class.
- Add a method to the RPC::XML::basic_type superclass so that return values can be directly tested with something like is_fault(), thus eliminating the need for $resp->value->value calls to get the return value as Perl data. There's no reason for a call to RPC::XML::Client->send_request to return a full response object, when all the user wants is the data-or-error return value.
- Make the above change to send_request().
SAX
Matts on 2002-01-17T10:12:19
Any chance of removing the dependency on XML::Parser, nudge nudge, wink wink...
:-)
Re:SAX
rjray on 2002-01-17T22:18:26
Yes, but not on the same schedule as the above. I do want to make it less dependant on any specific parser (and the recent XML::SAX and XML::SAX::PurePerl promise to be a great step in that direction). But I want the functionality itself to be stabilized and implemented, before I go back and re-engineer things that would be otherwise transparent to the end-user.
