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

XMLRPC::Lite +

Expand Messages
  • dpk
    Hi paul, Ive run into the undef serialization bug in XMLRPC::Lite (nasty), and saw on the xmlrpc list that you might implement the extention in the next
    Message 1 of 5 , Jul 10, 2001
    • 0 Attachment
      Hi paul, Ive run into the undef serialization bug in XMLRPC::Lite
      (nasty), and saw on the xmlrpc list that you might implement the <nil/>
      extention in the next release. Do you plan on serializing all undef's
      into <nil/> or will it be a configuration setting? How long do you
      think it'll be before we can get a chance to beta test your changes?
      dpk

      __________________________________________________
      Do You Yahoo!?
      Get personalized email addresses from Yahoo! Mail
      http://personal.mail.yahoo.com/
    • Paul Kulchenko
      Hi, dpk! ... There are several of them that are fixed already. ! number of fixes in XMLRPC::Lite fixed requirement (thanks to Matthew Krenzer and Dana
      Message 2 of 5 , Jul 10, 2001
      • 0 Attachment
        Hi, dpk!

        > Hi paul, Ive run into the undef serialization bug in XMLRPC::Lite
        > (nasty), and saw on the xmlrpc list that you might implement the
        There are several of them that are fixed already.

        ! number of fixes in XMLRPC::Lite
        fixed <string> requirement (thanks to Matthew Krenzer and Dana
        Powers)
        fixed skipping of empty slot (thanks to Jon Udell)
        fixed serialization of "0"/""/undef values (thanks to Michael E.
        Gage)
        fixed autodispatch (thanks to Craig Kelley)

        <nil/> is an extension and Dave Winer (author of XML-RPC) doesn't
        encourage to use it. SOAP::Lite might support <nil/> but only on
        parser side, it will NOT generate it. undef values are encoded as
        empty elements and can be properly de/serialized almost in all cases.

        > into <nil/> or will it be a configuration setting? How long do you
        > think it'll be before we can get a chance to beta test your
        > changes?
        Good question. I planed/promissed to make a release almost two weeks
        ago, then delayed it for a couple of reasons, but mainly to include
        support for SOAP1.2. I plan to release code during this weekend after
        extensive testing. XMLRPC::Lite module is pretty independent from
        core piece, but there are couple of changes (like fix for empty
        slots) that require code to be released together with SOAP::Lite. You
        should not be disappointed :).

        Best wishes, Paul.

        --- dpk <beatdown_1_2@...> wrote:
        > Hi paul, Ive run into the undef serialization bug in XMLRPC::Lite
        > (nasty), and saw on the xmlrpc list that you might implement the
        > <nil/>
        > extention in the next release. Do you plan on serializing all
        > undef's
        > into <nil/> or will it be a configuration setting? How long do you
        > think it'll be before we can get a chance to beta test your
        > changes?
        > dpk
        >
        > __________________________________________________
        > Do You Yahoo!?
        > Get personalized email addresses from Yahoo! Mail
        > http://personal.mail.yahoo.com/
        >
        > To unsubscribe from this group, send an email to:
        > soaplite-unsubscribe@yahoogroups.com
        >
        >
        >
        > Your use of Yahoo! Groups is subject to
        > http://docs.yahoo.com/info/terms/
        >
        >


        __________________________________________________
        Do You Yahoo!?
        Get personalized email addresses from Yahoo! Mail
        http://personal.mail.yahoo.com/
      • Weidong Wang
        Thanks for the reply, Paul. How do I add header and other elements to body and still use the normal call convention? Is it to use addheader()? Can you provide
        Message 3 of 5 , Jul 11, 2001
        • 0 Attachment
          Thanks for the reply, Paul.
           
          How do I add header and other elements to body and still use the normal call convention?
          Is it to use addheader()? Can you provide an example for using it?
          Also, how to add body fields?
           
          Thanks.
           
          Weidong
           
          ----- Original Message -----
          Sent: Tuesday, July 10, 2001 6:09 PM
          Subject: Re: [soaplite] How to send a serialized SOAP request?

          Hi, Weidong!

          --- Weidong Wang <wwang@...> wrote:
          > Since I need to define my own SOAP Header and have user defined
          > data fields in the body, I turn to Serializer->envelope() to
          > generate a serialized SOAP request. That works fine.
          You don't need to. You can add SOAP Headers and user defined fields
          and objects and still should be able to reuse everything else.

          > But I can't find a way to send such already serialized request over
          > to the server. I suppose I still need to set uri() and proxy(), but
          > how do I make the call? I tried using call(), but it is trying to
          > serialize again.
          But if you still need it, then you need to call send_receive method
          (it's common for all transports, so you don't need to worry about
          transport level) and pass parameters there. Take a look into call()
          method that does it. Be prepared however that this interface is not
          documented and will change in future versions. I promise :)

          Let me know if you need more information.

          Best wishes, Paul.

          __________________________________________________
          Do You Yahoo!?
          Get personalized email addresses from Yahoo! Mail
          http://personal.mail.yahoo.com/

          To unsubscribe from this group, send an email to:
          soaplite-unsubscribe@yahoogroups.com



          Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
        Your message has been successfully submitted and would be delivered to recipients shortly.