I've implemented a session-based persistant application using the PEAR::SOAP
class without having to modify the libs. I used PEAR::Auth to implemented
something like the following:
$client->login(user,pass);
while(1) {
$client->getNewMessages();
}
$client->logout();
Obviously this isn't the actual code, but the general idea is that the
session keeps track of what messages have already been sent to the client,
and only sends messages that have arrived since the last time the client
checked for messages. If the client logs in again, all messages will be
sent initially, then all messages we be resent on the first request, then
each additional request will only send new messages.
Since it uses the Auth class, and the Auth class supports storing data via
the setAuthData and getAuthData methods, you could easily store object
information in the session as well, and use this to make a persistant
webservice. This method uses cookies, so technically it's not a great way
of doing things since SOAP should work across multiple transports, but for
most practical applications it's a 5 minute hack that accomplishes the task.
Also, I've tested it with .NET and PEAR::SOAP clients and they both appear
to grok it just fine. Haven't tested with other clients yet, though I'm
sure most of them will work.
Hope this helps,
-Javier
-----Original Message-----
From: Will Green [mailto:will@hotgazpacho.org]
Sent: Friday, October 17, 2003 8:45 AM
To: soap@lists.php.net
Subject: Persistance
Ok, first, I do understand that, as of 0.7.5, PEAR::SOAP does not have
persistance. I got to thinking why this hasn't been implemented (and
how I might go about implementing it), when I came across this question:
What would necessitate the use of persistent server-side objects?
More specifically, is there something that session-based persistence can
achieve that one cannot accomplish using SOAP headers and manually
serializing the object at the end of the request?
About 3 months ago, someone posted to the list that they wanted their
client to do something like:
$c->setKey( 'abc123' );
$key = $c->getKey();
Could this not just as easily be accomplished by sending the key in a
SOAP header, having the SOAP server handle that header by setting it as
an instance variable of the server-side object, then answering the
request in the SOAP body?
Seems to me if you needed to truly persist the object across requests,
you could have the server's response include a Unique ID for the object.
If you needed access to that specific object on subsequent requests,
you could send the Object ID as a header, and then the server could
handle de-serializing the object before handling the body of your request.
So, persistence seems to be something that should be handled by the
application developer, rather than the PEAR::SOAP library.
I am wide open to feedback on this matter!
==
Will Green
--
PHP Soap Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Soap Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
