Loading ...
Sorry, an error occurred while loading the content.

object-by-reference

Expand Messages
  • Robert Barta
    Hi, I m struggling a bit with various issues with the o-b-r feature which I learned to love and do not want to give up for the rest of my life :-) In the
    Message 1 of 5 , Feb 15, 2001
    • 0 Attachment
      Hi,

      I'm struggling a bit with various issues with the o-b-r
      feature which I learned to love and do not want to give
      up for the rest of my life :-)

      In the current implementation SOAP::Lite does NOT forward
      any DESTROY invocation on the client side to the server:

      The responsible AUTOLOADer does simply a

      return if $method eq 'DESTROY';

      As I deal with quite fat data structures on the server
      side, it would be rather convenient to inform the server
      that the object is not any longer needed.

      I was thinking that maybe the client side could look
      somehow symmetrical to the server side:

      use SOAP::Lite +autodispatch,
      uri => 'http://my.own.site.com/My/Parameters',
      proxy => 'http://localhost:8081/', # local daemon
      server
      dispatch_for => [ 'My::SessionIterator' ]
      ;

      So I explicitely define WHICH objects I would like to autodispatch.
      Then, maybe the AUTOLOADer can look like this:

      return unless grep (ref ($_[0], @{$soap->{_dispatch_for}});

      Maybe the syntax can be simplified as

      use SOAP::Lite
      autodispatch => [ 'My::SessionIterator' ],
      ...

      but I am unable to get this running without compiler complaint. The
      +autodispatch syntax is too weird to me, though....

      \rho
    • Paul Kulchenko
      Hi, Robert! ... Thanks for your support. Hope we ll win this battle :)). ... True. One of the goals was provide exactly the same interface on client side for
      Message 2 of 5 , Feb 16, 2001
      • 0 Attachment
        Hi, Robert!

        --- Robert Barta <rho@...> wrote:
        > I'm struggling a bit with various issues with the o-b-r
        > feature which I learned to love and do not want to give
        > up for the rest of my life :-)
        Thanks for your support. Hope we'll win this battle :)).

        > In the current implementation SOAP::Lite does NOT forward
        > any DESTROY invocation on the client side to the server:
        True. One of the goals was provide exactly the same interface on
        client side for o-b-r object as for usual one, so there is no
        difference on client side and client doesn't know that it should send
        something there. I'm working on coule of modules that will require
        tight intergration between client and server and when it'll be done
        probably o-b-r will be redesigned. Client MAY provide support for it
        creating handler that will tell server that we don't need anymore
        this object, but I'm not sure about the details yet (though it could
        be very similar to your proposal on client side). Stil working,
        working.... :)) Thanks a lot.

        Best wishes, Paul.


        >
        > The responsible AUTOLOADer does simply a
        >
        > return if $method eq 'DESTROY';
        >
        > As I deal with quite fat data structures on the server
        > side, it would be rather convenient to inform the server
        > that the object is not any longer needed.
        >
        > I was thinking that maybe the client side could look
        > somehow symmetrical to the server side:
        >
        > use SOAP::Lite +autodispatch,
        > uri => 'http://my.own.site.com/My/Parameters',
        > proxy => 'http://localhost:8081/', # local
        > daemon
        > server
        > dispatch_for => [ 'My::SessionIterator' ]
        > ;
        >
        > So I explicitely define WHICH objects I would like to autodispatch.
        > Then, maybe the AUTOLOADer can look like this:
        >
        > return unless grep (ref ($_[0], @{$soap->{_dispatch_for}});
        >
        > Maybe the syntax can be simplified as
        >
        > use SOAP::Lite
        > autodispatch => [ 'My::SessionIterator' ],
        > ...
        >
        > but I am unable to get this running without compiler complaint. The
        >
        > +autodispatch syntax is too weird to me, though....
        >
        > \rho
        >
        > ------------------------ Yahoo! Groups Sponsor
        >
        > To unsubscribe from this group, send an email to:
        > soaplite-unsubscribe@yahoogroups.com
        >
        >
        >


        __________________________________________________
        Do You Yahoo!?
        Get personalized email addresses from Yahoo! Mail - only $35
        a year! http://personal.mail.yahoo.com/
      • Ray Rizzuto
        Paul, Is there a way for the server to get the IP address of the client if the transport is tcp or http? For http, can I get access to the environment
        Message 3 of 5 , Feb 16, 2001
        • 0 Attachment
          Paul,
           
          Is there a way for the server to get the IP address of the client if the transport is tcp or http?  For http, can I get access to the environment variables, such as REMOTE_USER?
           
          Is there a mechanism to "filter" requests in the server so that I can use the client address to limit access to local addresses? 
           
          Can a server be also a client?  I.e. can I serve up an an object that makes use of other remote SOAP objects to handle the request?
           
          Ray
           
        • Paul Kulchenko
          Hi, Ray! ... Definitely. Exactly as from CGI app. No restrictions. ... You may check IP and die in your application if something is wrong. Client will get
          Message 4 of 5 , Feb 16, 2001
          • 0 Attachment
            Hi, Ray!
            --- Ray Rizzuto <ray.rizzuto@...> wrote:
            > Is there a way for the server to get the IP address of the client
            > if the
            > transport is tcp or http? For http, can I get access to the
            > environment variables, such as REMOTE_USER?
            Definitely. Exactly as from CGI app. No restrictions.

            > Is there a mechanism to "filter" requests in the server so that I
            > can use the client address to limit access to local addresses?
            You may check IP and "die" in your application if something is wrong.
            Client will get message from die.

            > Can a server be also a client? I.e. can I serve up an an object
            > that makes use of other remote SOAP objects to handle the request?
            Absolutely. Actually SOAP::Lite should be already loaded, so just
            make new object and fire your request as you usually do from client
            side.

            You should be able to do everything you'd like to and there is no
            limitation on server side. You MAY have difficulties in returning
            objects (they MAY be non serializable, like filehandles), but module
            implements and serializes everything that could be serialized as far
            as I understand Perl. Let me know if you find any restrictions or
            limitations.

            Best wishes, Paul.

            __________________________________________________
            Do You Yahoo!?
            Get personalized email addresses from Yahoo! Mail - only $35
            a year! http://personal.mail.yahoo.com/
          • Ray Rizzuto
            Paul, If I m using SOAP::TRANSPORT::HTTP::Daemon or SOAP::TRANSPORT::TCP, how can I get the IP address? Can I get CGI variables if I m running
            Message 5 of 5 , Feb 17, 2001
            • 0 Attachment
              Paul,

              If I'm using SOAP::TRANSPORT::HTTP::Daemon or SOAP::TRANSPORT::TCP,
              how can I get the IP address?

              Can I get CGI variables if I'm running SOAP::TRANSPORT::HTTP::Daemon?

              Is there a way to filter at the server level without modifying the
              object being served? I.e. once I call the handle function, I don't
              get "control" till my method's are called. I want to have a filter
              which is called by handle before the actual class is called.

              Ray
              --- In soaplite@y..., Paul Kulchenko <paulclinger@y...> wrote:
              > Hi, Ray!
              > --- Ray Rizzuto <ray.rizzuto@u...> wrote:
              > > Is there a way for the server to get the IP address of the client
              > > if the
              > > transport is tcp or http? For http, can I get access to the
              > > environment variables, such as REMOTE_USER?
              > Definitely. Exactly as from CGI app. No restrictions.
              >
              > > Is there a mechanism to "filter" requests in the server so that I
              > > can use the client address to limit access to local addresses?
              > You may check IP and "die" in your application if something is
              wrong.
              > Client will get message from die.
              >
              > > Can a server be also a client? I.e. can I serve up an an object
              > > that makes use of other remote SOAP objects to handle the request?
              > Absolutely. Actually SOAP::Lite should be already loaded, so just
              > make new object and fire your request as you usually do from client
              > side.
              >
              > You should be able to do everything you'd like to and there is no
              > limitation on server side. You MAY have difficulties in returning
              > objects (they MAY be non serializable, like filehandles), but module
              > implements and serializes everything that could be serialized as far
              > as I understand Perl. Let me know if you find any restrictions or
              > limitations.
              >
              > Best wishes, Paul.
              >
              > __________________________________________________
              > Do You Yahoo!?
              > Get personalized email addresses from Yahoo! Mail - only $35
              > a year! http://personal.mail.yahoo.com/
            Your message has been successfully submitted and would be delivered to recipients shortly.