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

Re: [soapbuilders] UserLand's interop endpoint up

Expand Messages
  • Dave Winer
    Simon, I added a link to this on the docs page for the Manila interface. http://www.xml-rpc.com/manilaRpcSpec This way no one can miss it. Sorry for not
    Message 1 of 22 , Nov 10, 2001
    • 0 Attachment
      Simon, I added a link to this on the docs page for the Manila interface.

      http://www.xml-rpc.com/manilaRpcSpec

      This way no one can miss it. Sorry for not linking it in sooner.

      Dave


      ----- Original Message -----
      From: "Simon Fell" <soap@...>
      To: <soapbuilders@yahoogroups.com>
      Sent: Saturday, November 10, 2001 12:26 PM
      Subject: Re: [soapbuilders] UserLand's interop endpoint up


      > FWIW, i wrote a WSDL description for Manila a while back
      > http://www.pocketsoap.com/interop/manila.wsdl
      >
      > Cheers
      > Simon
      >
      > On Sat, 10 Nov 2001 13:35:21 -0500, in soap you wrote:
      >
      > >> Jake is taking most of the day off today
      > >
      > >Sluggard. :)
      > >
      > >> What we want is to be able to say to developers: "If you download this
      > >> toolkit you'll be able to connect your text editor or outliner into our
      CMS
      > >> through SOAP 1.1."
      > >
      > >As I said before, the answer is it depends. Since you do a subset of
      > >full SOAP, it's quite possible that some other toolkit will send you
      > >messages that you can't parse. You can lessen the problem by defining
      > >your interface so that the "most obvious" encoding falls into the set
      > >that you support; for example, no multi-dimensional arrays. As to how
      > >to define those interfaces, that's up to your implementors.
      > >
      > >But once they're defined, I betcha many folks here would be glad to send
      > >you sample packets encoded by their toolkits. Then you could make your
      > >own table just like Sam's. :) But if you want that to happen, then you
      > >should express your interface in terms of XMLSchema, maybe even WSDL.
      > >(Once you have schema, going to WSDL is usually trivial.) Prose
      > >descriptions are not helpful here. You're defining an interface, and
      > >you need an interface definition language, and XML Schema is,
      > >pragmatically speaking, the only XML IDL around right now (ALIDL et al
      > >notwithstanding). Yes it's huge and a pain in the ass, but you can
      > >probably understand enough of it in a day so that you can write the
      > >definitions of your interfaces.
      > >
      > >> And the really big question -- is this all you want from us? Or is this
      the
      > >> beginning of a slippery slope where I lose Jake on my devteam and have
      to
      > >> tell my customers to wait again?
      > >
      > >"We" want nothing. :) YOUR customers will want to interop. It's gonna be
      > >a set of judgement calls. As you do the "market is a conversation"
      > >thang with your users, you will find out what sending-side toolkits are
      > >important to them, and you might have to do some more work.
      > >
      > >You can't remove that fundamental tension: Frontier doesn't implement
      > >all of SOAP, and the community is not going to limit itself to the BDG
      > >anymore. So, the question you have to ask yourself is, do you feel
      > >lucky? Sorry :), I mean, did you implement the RIGHT subset? Probably,
      > >and in this note I've tried to show a way that folks here might be able
      > >to help you get a more definitive -- no, pragmatic -- answer.
      > >
      > > /r$
      >
      >
      > -----------------------------------------------------------------
      > This group is a forum for builders of SOAP implementations to discuss
      implementation and interoperability issues. Please stay on-topic.
      >
      > To unsubscribe from this group, send an email to:
      > soapbuilders-unsubscribe@yahoogroups.com
      >
      >
      >
      > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
      >
      >
    • Jake Savin
      ... Hi Sam, I modified the configuration on the Frontier endpoint so that it now supports both SOAPAction values: SOAPAction: http://soapinterop.org/ -or-
      Message 2 of 22 , Nov 10, 2001
      • 0 Attachment
        on 11/9/01 7:06 PM, Sam Ruby at rubys@... wrote:

        > Jake Savin wrote:
        >>
        >> SOAPAction: urn:soapinterop
        >
        > Is there any way that you could update it to match the SOAPAction specified
        > by http://www.whitemesa.com/interop.htm, i.e., "http://soapinterop.org/" ?
        >
        > - Sam Ruby

        Hi Sam,

        I modified the configuration on the Frontier endpoint so that it now
        supports both SOAPAction values:

        SOAPAction: "http://soapinterop.org/"

        -or-

        SOAPAction: "urn:soapinterop"

        This way clients can test against the Frontier endpoint using the new value,
        and clients which still use the older value won't break.

        -Jake
      • nahi@mwd.biglobe.ne.jp
        Hi Jake, ... SOAP4R client - Frontier server test results: 21/49 http://www.jin.gr.jp/~nahi/Ruby/SOAP4R/wiki.cgi?
        Message 3 of 22 , Nov 10, 2001
        • 0 Attachment
          Hi Jake,

          > I modified the configuration on the Frontier endpoint so that it now
          > supports both SOAPAction values:
          >
          > SOAPAction: "http://soapinterop.org/"
          >
          > -or-
          >
          > SOAPAction: "urn:soapinterop"

          SOAP4R client - Frontier server test results: 21/49
          http://www.jin.gr.jp/~nahi/Ruby/SOAP4R/wiki.cgi?
          cmd=view;name=InteropResults%3A%3ASOAP4R%2F1.3.8-Frontier

          Hope this helps,
          // NaHi
        • Bob Cunnings
          Hi Jake, Looks good. The Round 2 endpoint table has been updated. Testing with the WM client discovers that all supported methods in the base group pass
          Message 4 of 22 , Nov 10, 2001
          • 0 Attachment
            Hi Jake,

            Looks good. The Round 2 endpoint table has been updated. Testing with the WM client discovers that all supported methods in the "base" group pass except echoStructArray, which returns an incorrect arrayType value:

            ...<Result SOAP-ENC:arrayType="urn:SOAPStruct[3]" xmlns:urn="http://www.xmethods.com/service" xsi:type="SOAP-ENC:Array">...

            The SOAPStruct type name is qualified by the wrong namespace... http://soapinterop.org/xsd is expected [1].

            RC

            [1] http://www.whitemesa.com/interop/proposal2.html#echoStructArray

            > on 11/9/01 7:06 PM, Sam Ruby at rubys@... wrote:
            >
            > > Jake Savin wrote:
            > >>
            > >> SOAPAction: urn:soapinterop
            > >
            > > Is there any way that you could update it to match the SOAPAction specified
            > > by http://www.whitemesa.com/interop.htm, i.e., "http://soapinterop.org/" ?
            > >
            > > - Sam Ruby
            >
            > Hi Sam,
            >
            > I modified the configuration on the Frontier endpoint so that it now
            > supports both SOAPAction values:
            >
            > SOAPAction: "http://soapinterop.org/"
            >
            > -or-
            >
            > SOAPAction: "urn:soapinterop"
            >
            > This way clients can test against the Frontier endpoint using the new value,
            > and clients which still use the older value won't break.
            >
            > -Jake
            >
            >
            >
            > -----------------------------------------------------------------
            > This group is a forum for builders of SOAP implementations to discuss implementation and interoperability issues. Please stay on-topic.
            >
            > To unsubscribe from this group, send an email to:
            > soapbuilders-unsubscribe@yahoogroups.com
            >
            >
            >
            > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
            >
            >
          • Sam Ruby
            ... Please take a moment to check out http://www.whitemesa.com/interop.htm . It contains three sections. First is a description of the scenarios. In both
            Message 5 of 22 , Nov 11, 2001
            • 0 Attachment
              Dave Winer wrote:
              >
              > So Sam has a table of implementations he interops with, are there other
              > tables floating around?

              Please take a moment to check out http://www.whitemesa.com/interop.htm .
              It contains three sections.

              First is a description of the scenarios. In both human readable prose
              and in machine readable formats.

              Second is a list of active endpoints.

              Third is a list of published results.

              In addition to these three sections, at the bottom you can find a pointer
              to a "competing" registry, a back pointer to the previous effort, and the
              e-mail address of the maintainter of this page.

              > If anyone else has a perspective on what interop means in November 2001,
              I'm
              > very interested in hearing more.

              I see a community where we all test to a set of base tests, and compare
              results. I can tell you that I have made coding decisions based on these
              results. The some implementations make heavy use of href's, so the Axis
              implemention will accept them, but as not all implementations accept these,
              I have chosen to avoid using href's for simple structs and simple arrays,
              but in some cases (like arrays of structs) I will make use of them.

              Some implementations test some extra edge cases. The Ruby (no relation)
              scripting language folks, for example, have added a fair number of extra
              tests.

              - Sam Ruby
            • Sam Ruby
              Like WhiteMesa, the Apache implementations have trouble parsing Frontier s response from echoStructArray. Three new data types that have been introduced into
              Message 6 of 22 , Nov 11, 2001
              • 0 Attachment
                Like WhiteMesa, the Apache implementations have trouble parsing Frontier's
                response from echoStructArray.

                Three new data types that have been introduced into the testing since
                April: HexBinary, Decimal, and Binary. I have colleagues in IBM that tell
                me that decimal is very important to business and financial types.

                - Sam Ruby
              Your message has been successfully submitted and would be delivered to recipients shortly.