Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

Diff of /branches/0.71/lib/SOAP/Transport.pod [r362] .. [r363] Maximize Restore

  Switch to side-by-side view

--- a/branches/0.71/lib/SOAP/Transport.pod
+++ b/branches/0.71/lib/SOAP/Transport.pod
@@ -4,7 +4,7 @@
 # SOAP::Lite is free software; you can redistribute it
 # and/or modify it under the same terms as Perl itself.
 #
-# $Id: Transport.pod 346 2010-03-12 20:57:07Z kutterma $
+# $Id: Transport.pod 363 2010-03-18 20:23:09Z kutterma $
 #
 # ======================================================================
 
@@ -107,16 +107,6 @@
 (Required for server classes only.) This method is the central point for the various server classes to provide an interface to handling requests. The exact set and nature of parameters generally varies based on the classes themselves.
 
 =back
-
-=head2 SOAP::Transport::FTP
-
-The SOAP::Transport::FTP module is automatically loaded by the SOAP::Transport portion of the client structure. It is brought in when an endpoint is specified via the proxy method that starts with the characters, ftp://. This module provides only a client class. 
-
-=head3 SOAP::Transport::FTP::Client
-
-Inherits from: L<SOAP::Client>. 
-
-Support is provided for clients to connect to FTP servers using SOAP. The methods defined within the class are just the basic new and send_receive. 
 
 =head2 SOAP::Transport::HTTP
 
@@ -490,41 +480,6 @@
 
 =back
 
-=head2 SOAP::Transport::JABBER
-
-This class uses the Net::Jabber classes to abstract the Jabber protocol away from the direct notice of the application. Besides maintaining any needed objects internally, the package also uses a separate class as a proxy between communication layers, SOAP::Transport::JABBER::Query. The Jabber support provides both client and server classes. 
-
-=head3 SOAP::Transport::JABBER::Client
-
-Inherits from: L<SOAP::Client>, L<Net::Jabber::Client>. 
-This class provides localized implementations for both the new and send_receive methods, neither of which are changed in terms of interface. The only difference is that the send_receive method doesn't directly use the action hash key on the input it receives. In addition to these two basic methods, the server class overrides the endpoint
-method it would otherwise inherit from SOAP::Client: 
-
-=over
-
-=item endpoint
-
-In the general sense, this still acts as a basic accessor method, with the same get value/set value behavior used consistently through the SOAP::Lite module. The difference between this version and most others is that when the endpoint is initially set or is changed, the client object makes the connection to the Jabber endpoint, sending the proper authentication credentials and setting up the conversation mechanism using the SOAP::Transport::JABBER::Query class as a delegate. It then calls the superclass endpoint method to ensure that all other related elements are taken care of.
-
-=back
-
-=head3 SOAP::Transport::JABBER::Server
-
-Inherits from: L<SOAP::Server>. 
-
-The server class provided for Jabber support defines a slightly different interface to the constructor. The server manages the Jabber communication by means of an internal Net::Jabber::Client instance. In a fashion similar to that used by SOAP::Transport::HTTP::Daemon, the server class catches methods that are meant for the Jabber client and treats them as if the class inherits directly from that class, without actually doing so. In doing so, the handle method is implemented as a frontend to the Process method of the Jabber client class. The difference in the interface to the constructor is: 
-
-=over
-
-=item new(I<URI>, I<optional server key/value options>)
-
-    $srv = SOAP::Transport::JABBER::Server-> new($uri);
-
-The constructor for the class expects that the first argument will be a Jabber-style URI, followed by the standard set of optional key/value pairs of method names and their parameters. All the method/parameter
-pairs are delegated to the superclass constructor; only the Jabber URI is handled locally. It's used to set up the Net::Jabber::Client instance that manages the actual communications.
-
-=back
-
 =head2 SOAP::Transport::LOCAL
 
 The SOAP::Transport::LOCAL module is designed to provide a no-transport client class for tracing and debugging communications traffic. It links SOAP::Client and SOAP::Server so that the same object that "sends" the request also "receives" it. 
@@ -558,65 +513,6 @@
 
 When invoked, the send_receive method uses the MIME::Lite package to encapsulate and transmit the message. Because mail messages are one-way communications (the reply being a separate process), there is no response message to be returned by the method. Instead, all the status-related attributes (code, message, status, is_success) are set, and no value is explicitly returned. 
 
-=head2 SOAP::Transport::MQ
-
-This class provides implementations of both client and server frameworks built on IBM's Message Queue set of classes. The SOAP objects encapsulate additional objects from these classes, creating and using them behind the scenes as needed. 
-
-=head3 SOAP::Transport::MQ::Client
-
-Inherits from: L<SOAP::Client>. 
-
-The client class provides two methods specific to it, as well as specialized versions of the endpoint and send_receive methods. It also provides a localized new method, but the interface isn't changed from the superclass method. The new methods are: 
-
-=over 
-
-=item requestqueue
-
-    $client->requestqueue->Put(message => $request);
-
-Manages the MQSeries::Queue object the client uses for enqueuing requests to the server. In general, an application shouldn't need to directly access this attribute, let alone set it. If setting it, the new value should be an object of (or derived from) the MQSeries::Queue class.
-
-=item replyqueue
-
-    $client->replyqueue(MQSeries::Queue->new(%args));
-
-Manages the queue object used for receiving messages back from the designated server (endpoint). It is also primarily for internal use, though if the application needs to set it explicitly, the new value should be an object of (or derived from) the MQSeries::Queue class.
-
-=back
-
-The two previous methods are mainly used by the localized versions of the methods: 
-
-=over
-
-=item endpoint
-
-This accessor method has the same interface as other similar classes but is worth noting for the internal actions that take place. When the endpoint is set or changed, the method creates a queue-manager object (from the MQSeries::QueueManager class) and references this object when creating queues for replies and requests using the methods described earlier. The URI structure used with these classes (strings beginning with the characters mq://user@host:port) contains the information needed for these operations.
-
-=item send_receive
-
-This method uses the same interface as other classes, but makes use of only the endpoint and envelope keys in the hash-table input data. The endpoint key is needed only if the client wishes to switch endpoints prior to sending the message. The message (the value of the envelope key) is inserted into the queue stored in the requestqueue attribute. The client then waits for a reply to the message to appear in the queue stored in the replyqueue attribute.
-
-=back
-
-=head3 SOAP::Transport::MQ::Server
-
-Inherits from: L<SOAP::Server>. 
-
-The server class also defines requestqueue and replyqueue methods under the same terms as the client class. Of course, the server reads from the request queue and writes to the reply queue, the opposite of the client's behavior.
-The methods whose functionality are worth noting are: 
-
-=over
-
-=item new(URI, optional parameters)
-
-When called, the constructor creates the MQSeries::QueueManager object and the two MQSeries::Queue objects, similar to what the client does inside its endpoint method. Like the Jabber server described earlier, the first argument to this constructor is expected to be the URI that describes the server itself. The remainder of the arguments are treated as key/value pairs, as with other class constructors previously described.
-
-=item handle
-
-When this method is called, it attempts to read a pending message from the request-queue stored on the requestqueue attribute. The message itself is passed to the handle method of the superclass, and the result from that operation is enqueued to the replyqueue object. This process loops until no more messages are present in the request queue. The return value is the number of messages processed. The reads from the request queue are done in a nonblocking fashion, so if there is no message pending, the method immediately returns with a value of zero.
-
-=back
-
 =head2 SOAP::Transport::POP3
 
 POP3 support is limited to a server implementation. Just as the MAILTO class detailed earlier operates by sending requests without expecting to process a response, the server described here accepts request messages and dispatches them without regard for sending a response other than that which POP3 defines for successful delivery of a message.