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

OpenCola's gamble?

Expand Messages
  • Dave Winer
    I just read OpenCola s technology overview. http://www.opencola.com/software/octech.html Interesting they re wanting to do better than Akamai at caching
    Message 1 of 24 , Feb 11, 2001
    • 0 Attachment
      I just read OpenCola's technology overview.

      http://www.opencola.com/software/octech.html

      Interesting they're wanting to do better than Akamai at caching content
      closer to the user. I believe this could work, if they attain critical mass.
      Also interesting is that they're not using XML-RPC or SOAP.

      My comment: I think XML-RPC or SOAP could do what they do. I don't know
      their business model, or if their goal is to get lots of compatible nodes.
      If would seem so, XML-RPC would, by far, be the best choice. SOAP would be
      second, and a new flavor of XML-over-the-wire, imho, a distant third.

      I know some OpenCola people are here on this list, so I thought it would be
      interesting to learn why they're gambling on a new wire format, instead of
      joining up with the existing formats. It's a lot of work to get developers
      to swing together. It would also be interesting to support them in our
      software, but that's more work for us if they use something different.

      Dave

      ______________________________
      Dave Winer, UserLand Software
      Daily notes: http://www.scripting.com/
      "It's even worse than it appears."
    • Wesley M. Felter
      ... I don t really care about this issue one way or the other, but I can t resist. Let s imagine that OpenCola does use XML-RPC or SOAP. What now? Anybody who
      Message 2 of 24 , Feb 11, 2001
      • 0 Attachment
        On Sun, 11 Feb 2001, Dave Winer wrote:

        > I just read OpenCola's technology overview.
        >
        > http://www.opencola.com/software/octech.html
        >
        > Interesting they're wanting to do better than Akamai at caching content
        > closer to the user. I believe this could work, if they attain critical mass.
        > Also interesting is that they're not using XML-RPC or SOAP.
        >
        > My comment: I think XML-RPC or SOAP could do what they do. I don't know
        > their business model, or if their goal is to get lots of compatible nodes.
        > If would seem so, XML-RPC would, by far, be the best choice. SOAP would be
        > second, and a new flavor of XML-over-the-wire, imho, a distant third.

        I don't really care about this issue one way or the other, but I can't
        resist.

        Let's imagine that OpenCola does use XML-RPC or SOAP. What now? Anybody
        who wants to interoperate with them still needs to implement a slew of
        OC-specific interfaces, so how much work has been saved? Either way it
        seems like thousands of lines of code. But it's hard to tell given the
        early state of OpenCola; hopefully somebody will smack me around if I'm
        wrong.

        Wesley Felter - wesf@... - http://www.cs.utexas.edu/users/wesf/
        "I want you to hit me as hard as you can." -- Tyler Durden
        "Damn, I want to get Slashdotted. We can handle it." -- Dave Winer
      • Dave Winer
        ... Nice to see I made your sig. Now if Taco or Hemos would just *DO IT* already. ;- Anyway, it s always good to use established interfaces, the people who
        Message 3 of 24 , Feb 11, 2001
        • 0 Attachment
          >>"Damn, I want to get Slashdotted. We can handle it." -- Dave Winer

          Nice to see I made your sig. Now if Taco or Hemos would just *DO IT*
          already. ;->

          Anyway, it's always good to use established interfaces, the people who have
          invested in those interfaces will help you promote your vision because it
          connects with theirs. We're at a point where *maybe* independent developers
          become fashionable again. I think to deserve that we have to make an effort
          where ever possible to help each other win. That's my philosophy.

          On the other hand, I've reinvented my share of protocols, I've heard that
          http-post and/or ftp could do everything xml-rpc and soap can and of course
          it's true.

          Dave
        • Lucas Gonze
          Question: why have both XML-RPC and SOAP, Dave? This has been an enduring mystery for me. A note about OpenCola s protocol - they use XPath, which is unusual
          Message 4 of 24 , Feb 11, 2001
          • 0 Attachment
            Question: why have both XML-RPC and SOAP, Dave? This has been an enduring mystery
            for me.

            A note about OpenCola's protocol - they use XPath, which is unusual but at least is a
            standard. Does anyone know what the specific appeal of XPath was?

            - Lucas



            > -----Original Message-----
            > From:
            > sentto-2063116-1292-981920215-lucas=worldos.com@...
            > [mailto:sentto-2063116-1292-981920215-lucas=worldos.com@....
            > com]On Behalf Of Dave Winer
            > Sent: Sunday, February 11, 2001 2:36 PM
            > To: decentralization@yahoogroups.com
            > Subject: [decentralization] OpenCola's gamble?
            >
            >
            > I just read OpenCola's technology overview.
            >
            > http://www.opencola.com/software/octech.html
            >
            > Interesting they're wanting to do better than Akamai at caching content
            > closer to the user. I believe this could work, if they attain critical mass.
            > Also interesting is that they're not using XML-RPC or SOAP.
            >
            > My comment: I think XML-RPC or SOAP could do what they do. I don't know
            > their business model, or if their goal is to get lots of compatible nodes.
            > If would seem so, XML-RPC would, by far, be the best choice. SOAP would be
            > second, and a new flavor of XML-over-the-wire, imho, a distant third.
            >
            > I know some OpenCola people are here on this list, so I thought it would be
            > interesting to learn why they're gambling on a new wire format, instead of
            > joining up with the existing formats. It's a lot of work to get developers
            > to swing together. It would also be interesting to support them in our
            > software, but that's more work for us if they use something different.
            >
            > Dave
            >
            > ______________________________
            > Dave Winer, UserLand Software
            > Daily notes: http://www.scripting.com/
            > "It's even worse than it appears."
            >
            >
            > To unsubscribe from this group, send an email to:
            > decentralization-unsubscribe@egroups.com
            >
            >
            >
            >
          • Dave Winer
            Lucas, why have Windows and Mac? The day Windows came out, would it be reasonable to expect all Mac users to disappear? There is momentum in XML-RPC. Just a
            Message 5 of 24 , Feb 11, 2001
            • 0 Attachment
              Lucas, why have Windows and Mac?

              The day Windows came out, would it be reasonable to expect all Mac users to
              disappear?

              There is momentum in XML-RPC. Just a fact. SOAP didn't change that, if
              anything it enhanced it.

              XML-RPC is our assurance that the gorillas that swing in SOAP-land pay
              attention to independent developers. If they don't we'll just keep using
              XML-RPC. Either way we win. I like those odds better than being dependent on
              the titans.

              Remember Netscape? As long as there was a choice in browsers we were
              powerful. As soon as Netscape abdicated, poof, there went the power.

              Dave


              ----- Original Message -----
              From: "Lucas Gonze" <lucas@...>
              To: <decentralization@yahoogroups.com>
              Sent: Sunday, February 11, 2001 11:59 AM
              Subject: RE: [decentralization] OpenCola's gamble?


              > Question: why have both XML-RPC and SOAP, Dave? This has been an enduring
              mystery
              > for me.
              >
              > A note about OpenCola's protocol - they use XPath, which is unusual but at
              least is a
              > standard. Does anyone know what the specific appeal of XPath was?
              >
              > - Lucas
              >
              >
              >
              > > -----Original Message-----
              > > From:
              > > sentto-2063116-1292-981920215-lucas=worldos.com@...
              > > [mailto:sentto-2063116-1292-981920215-lucas=worldos.com@....
              > > com]On Behalf Of Dave Winer
              > > Sent: Sunday, February 11, 2001 2:36 PM
              > > To: decentralization@yahoogroups.com
              > > Subject: [decentralization] OpenCola's gamble?
              > >
              > >
              > > I just read OpenCola's technology overview.
              > >
              > > http://www.opencola.com/software/octech.html
              > >
              > > Interesting they're wanting to do better than Akamai at caching content
              > > closer to the user. I believe this could work, if they attain critical
              mass.
              > > Also interesting is that they're not using XML-RPC or SOAP.
              > >
              > > My comment: I think XML-RPC or SOAP could do what they do. I don't know
              > > their business model, or if their goal is to get lots of compatible
              nodes.
              > > If would seem so, XML-RPC would, by far, be the best choice. SOAP would
              be
              > > second, and a new flavor of XML-over-the-wire, imho, a distant third.
              > >
              > > I know some OpenCola people are here on this list, so I thought it would
              be
              > > interesting to learn why they're gambling on a new wire format, instead
              of
              > > joining up with the existing formats. It's a lot of work to get
              developers
              > > to swing together. It would also be interesting to support them in our
              > > software, but that's more work for us if they use something different.
              > >
              > > Dave
              > >
              > > ______________________________
              > > Dave Winer, UserLand Software
              > > Daily notes: http://www.scripting.com/
              > > "It's even worse than it appears."
              > >
              > >
              > > To unsubscribe from this group, send an email to:
              > > decentralization-unsubscribe@egroups.com
              > >
              > >
              > >
              > >
              >
              >
              > To unsubscribe from this group, send an email to:
              > decentralization-unsubscribe@egroups.com
              >
              >
              >
            • Lucas Gonze
              ... I guess I always suspected that. Another question: is there any possibility of unifying XML-RPC and SOAP? ... MS. MS. MS. It s not bad to hate your
              Message 6 of 24 , Feb 11, 2001
              • 0 Attachment
                > There is momentum in XML-RPC. Just a fact. SOAP didn't change that, if
                > anything it enhanced it.

                I guess I always suspected that. Another question: is there any possibility of
                unifying XML-RPC and SOAP?

                > Remember Netscape? As long as there was a choice in browsers we were
                > powerful. As soon as Netscape abdicated, poof, there went the power.

                MS. MS. MS. It's not bad to hate your competitors, it's just bad to hate your
                customers. I have been spending a lot of time using Visio lately, and it's the
                typical experience with MS software - once you get past the first 90% of features it
                is overpromised and underdelivered.

                - Lucas
              • Dave Winer
                ... It doesn t seem very likely to me. Perhaps at an API level, inside each implementation, the distinction can be hidden. We ve got that working in Frontier,
                Message 7 of 24 , Feb 11, 2001
                • 0 Attachment
                  >>is there any possibility of unifying XML-RPC and SOAP?

                  It doesn't seem very likely to me.

                  Perhaps at an API level, inside each implementation, the distinction can be
                  hidden. We've got that working in Frontier, for a subset of SOAP. Works just
                  like XML-RPC.

                  Also you should know that everyone implements a subset of SOAP. This is the
                  unique interop challenge to SOAP, to agree on a subset that enough
                  implementations support to create something like a standard, so
                  SOAP-compatibility means something.

                  Comparatively, XML-RPC is more solid, it was more solid three years ago than
                  SOAP is today. There's almost no variability to the spec, so interop came
                  without pain. When our validator came online last summer, within a few days
                  all the implementations validated. It's not going so smoothly for SOAP, and
                  everyone who's dived into this knew this would happen. Now what?

                  Since this is the software industry everyone will try to figure out how I'm
                  leading you astray. But I have no conflict of interest, either protocol is
                  fine with me. I learned this lesson with Apple in the early 90s, when the
                  gorilla asks you to bend over you do it. That's why I enthusiastically
                  support SOAP, but at the same time am realistic about where it is. I have
                  nothing to lose by being realistic. I like that.

                  About MS and their software empathy, or lack of, we hope to help incentivize
                  them to treat you better. ;->

                  Dave
                • Lucas Gonze
                  It seems to me that protocol operations which are semantically equivalent should be amenable to XSLT, which brings up the possibility of a third, underlying,
                  Message 8 of 24 , Feb 11, 2001
                  • 0 Attachment
                    It seems to me that protocol operations which are semantically equivalent should be
                    amenable to XSLT, which brings up the possibility of a third, underlying, XML
                    protocol. Maybe SP for Substrate Protocol, or something.

                    That brings me to my favorite technological pipe dream, which is protocols defined as
                    object hierarchies. MUST operations should be in the root object. Two MAY
                    operations that don't make sense alone should belong to a common object derived from
                    the root, and other MAY operations which are not dependent on those can belong to
                    other objects. You need to define a set of rules for combining objects, a protocol
                    object standard for derivation, polymorphism, etc., but that seems like pretty well
                    known territory.

                    The cool thing that happens then is that problems where everyone is implementing
                    subsets of a spec are much easier to resolve. An implementation that supports a
                    protocol object must support every object from which it is derived. Every
                    implementation must support the root object. Every implementation must cast and
                    combine objects via the same rules. That way you know clearly when two
                    implementations are incompatible, because the supported objects can only be cast at a
                    level too low to support the necessary functionality.

                    dreaming on Sunday...

                    - Lucas
                  • Joey deVilla
                    I guess it s time to stop lurking. By way of a quick introduction, my name is Joey deVilla, and I m the Director of Developer Relations (and accordion player)
                    Message 9 of 24 , Feb 11, 2001
                    • 0 Attachment
                      I guess it's time to stop lurking. By way of a quick introduction, my name
                      is Joey deVilla, and I'm the Director of Developer Relations (and accordion
                      player) for OpenCola. I've recently been moved to this position and have
                      recently moved from Toronto to San Francisco, so I've been poring over
                      documentation in order to get a better view of the tech details behind
                      OpenCola's projects.

                      XRoad was designed by Karl Schroeder, our Structured Documents Specialist.
                      Prior to his life as an OpenColan, he was an SGML/XML guy at IBM Canada. I
                      don't know the details behind the decision-making process behind basing our
                      protocol on XPath rather than going with XML-RPC or SOAP, so I've forwarded
                      the original post to both him and our other Structured Docs guy, Chris
                      Smith. I'll post the reply as soon as I get it.

                      What I do know as that XRoad is based on the "object as document"
                      philosophy. HTTP and XML were not originally designed as a system for object
                      serialization, but rather document transmission. Objects in the OpenCola
                      network are treated as documents. As documents, they have pathnames (hence
                      the use of XPath), and pathnames give us a pretty simple addressing scheme.
                      Every peer on the network has its own URI, and services exposed by that peer
                      has a subpath of that URI. Your peer could use itself as the "root" node of
                      the network and use all the other peers it knows about in its directory
                      structure, or you can connect to a high-availability, highly knowlegeable
                      "root node" to get access to a large body of peers.

                      As I mentioned earlier, replies from our XML kahunas as soon as I get 'em.

                      ______________________________________________________
                      Joey deVilla - joey@...
                      Director of Developer Relations and Accordion Guy
                      OpenCola [http://opencola.com]
                    • Lucas Gonze
                      Nice to see you here, Joey. A question: do the URLs use fixed addressing based on domains and IPs, or do they support functional addressing a la Gnutella?
                      Message 10 of 24 , Feb 11, 2001
                      • 0 Attachment
                        Nice to see you here, Joey. A question: do the URLs use fixed addressing based on
                        domains and IPs, or do they support functional addressing a la Gnutella? What
                        protocol do they use - http://? opencola://?

                        - Lucas

                        > network are treated as documents. As documents, they have pathnames (hence
                        > the use of XPath), and pathnames give us a pretty simple addressing scheme.
                        > Every peer on the network has its own URI, and services exposed by that peer
                        > has a subpath of that URI. Your peer could use itself as the "root" node of
                      • Rael Dornfest
                        Howdy, ... There was some discussion about this on the XML-RPC mailing list[1]. Ken MacLeod pointed[2] at a HOWTO: Converting XML-RPC implementations to
                        Message 11 of 24 , Feb 11, 2001
                        • 0 Attachment
                          Howdy,

                          On Sun, 11 Feb 2001, Lucas Gonze wrote:

                          > > There is momentum in XML-RPC. Just a fact. SOAP didn't change that, if
                          > > anything it enhanced it.
                          >
                          > I guess I always suspected that. Another question: is there any possibility of
                          > unifying XML-RPC and SOAP?

                          There was some discussion about this on the XML-RPC mailing list[1]. Ken
                          MacLeod pointed[2] at a "HOWTO: Converting XML-RPC implementations to
                          SOAP"[3] (with a disclaimer that it "was written before SOAP
                          v1.1, but the changes are minor"). Ken did a quick implemention in his
                          SOAP-RPC Perl module[4].

                          Just a (possibly useful) data point.

                          Rael

                          [1] http://www.egroups.com/group/xml-rpc
                          [2] http://groups.yahoo.com/group/xml-rpc/message/1313
                          [3] http://LWProtocols.org/xmlrpc2soap.html
                          [4] http://bitsko.slc.ut.us/~ken/xml-rpc/SOAP-RPC-0.00.readme

                          ------------------------------------------------------------------
                          Rael Dornfest rael@...
                          Maven, http://www.oreillynet.com/~rael
                          The O'Reilly Network http://www.oreillynet.com
                          ------------------------------------------------------------------

                          The O'Reilly Peer-to-Peer Conference
                          February 14-16, 2001, San Francisco, CA
                          http://conferences.oreilly.com/p2p/
                        • Wesley M. Felter
                          ... Most of this makes sense (document-oriented (or resource-oriented as W3C types might say) protocol, using URIs for addressing), but URIs are for
                          Message 12 of 24 , Feb 11, 2001
                          • 0 Attachment
                            On Sun, 11 Feb 2001, Joey deVilla wrote:

                            > What I do know as that XRoad is based on the "object as document"
                            > philosophy. HTTP and XML were not originally designed as a system for object
                            > serialization, but rather document transmission. Objects in the OpenCola
                            > network are treated as documents. As documents, they have pathnames (hence
                            > the use of XPath), and pathnames give us a pretty simple addressing scheme.
                            > Every peer on the network has its own URI, and services exposed by that peer
                            > has a subpath of that URI.

                            Most of this makes sense (document-oriented (or "resource-oriented" as W3C
                            types might say) protocol, using URIs for addressing), but URIs are for
                            addressing documents, not XPath. XPath is for addressing *inside*
                            documents, which you haven't really mentioned.

                            Wesley Felter - wesf@... - http://www.cs.utexas.edu/users/wesf/
                          • allenjs@hotmail.com
                            ... There s a big difference, though. Without xml-rpc you would need to get each client and server to agree on the syntax of the calls; xml- rpc or soap just
                            Message 13 of 24 , Feb 11, 2001
                            • 0 Attachment
                              > http-post and/or ftp could do everything xml-rpc and soap can and
                              > of course it's true.

                              There's a big difference, though. Without xml-rpc you would need to
                              get each client and server to agree on the syntax of the calls; xml-
                              rpc or soap just give a common syntax that all clients and servers
                              can agree on beforehand so that at least *that* part can be dispensed
                              with early on. Really, that's a pretty huge productivity step
                              forward over what we had before.
                            • Gregory Alan Bolcer
                              ... Aren t you on the XP list? Greg
                              Message 14 of 24 , Feb 12, 2001
                              • 0 Attachment
                                Lucas Gonze wrote:
                                >
                                > It seems to me that protocol operations which are semantically equivalent should be
                                > amenable to XSLT, which brings up the possibility of a third, underlying, XML
                                > protocol. Maybe SP for Substrate Protocol, or something.
                                >
                                Aren't you on the XP list?

                                Greg
                              • Gregory Alan Bolcer
                                ... This brings me to my pet rant. (BTW, OpenCola/swarmcast are very interesting technologies). A long time ago, there was a hypertext/hypermedia discipline
                                Message 15 of 24 , Feb 12, 2001
                                • 0 Attachment
                                  Lucas Gonze wrote:

                                  > That brings me to my favorite technological pipe dream, which is protocols defined as
                                  > object hierarchies. MUST operations should be in the root object. Two MAY
                                  > operations that don't make sense alone should belong to a common object derived from
                                  > the root, and other MAY operations which are not dependent on those can belong to
                                  > other objects. You need to define a set of rules for combining objects, a protocol
                                  > object standard for derivation, polymorphism, etc., but that seems like pretty well
                                  > known territory.
                                  >

                                  This brings me to my pet rant. (BTW, OpenCola/swarmcast are very
                                  interesting technologies). A long time ago, there
                                  was a hypertext/hypermedia discipline who ranted very loudly
                                  about you can't use the Web for decentralized hyperlinking and
                                  every time you brought it up you got an earful about the list
                                  of things that was wrong with the Web for doing it. In fact there
                                  were 20 years of documents and research on the subject. The
                                  basis of hypermedia reserch was that each link and anchor had to be
                                  carefully controlled such that any added or removed links
                                  would be able to update all the other federated hypermedia
                                  link services all over the place and have a consistent
                                  hypermedia space.

                                  The Web eventually swept this
                                  very notion off its feet in response to scalability issues.
                                  Dangling links--which became 404 errors--were the savior
                                  of the Web. Now anyone could add or remove any information
                                  without having the transactional overhead of having to keep
                                  everyone who's pointing at an anchor consistent. There were
                                  some interesting open hypertext systems that combined the
                                  best of personal, closed annotation with the free-wheeling
                                  nature of the Web. [1] These type of systems allowed a Web
                                  client to talk to an intermediate proxy which annotated
                                  the Web content with locally stored link information. The point
                                  is, the Hypermedia industry were so caught up in keeping the
                                  data consistent that they completely ignored scalability issues
                                  and the Web eventually outscaled them all.

                                  Today, we have peer-to-peer architectures, and we have
                                  the distributed object discipline ranting about how you can't
                                  use the Web for decentralized computing because you can't
                                  keep transactional coherency across a variety of distributed
                                  nodes. Every time you tried to tell them about the
                                  mechanism of inconsistency for scalability, you got an earful.
                                  (My rant from almost exactly 3 years ago on this subject: [2]).

                                  The problem is, in a distributed object, why do you need to
                                  keep both the state AND behavior in the same place? This is
                                  one of the fundamental things I would like to change about
                                  the distributed object community. If you have a read/write
                                  Web protocol like DAV storing and object's state and a CGI/servlet-like
                                  behavior, there's no reason either have to be co-located on the
                                  same HTTP or other server. In fact, there's no reason that
                                  the behaviors need to be in the same language as the state
                                  access commands.

                                  So you have *decentralized objects*, not distributed objects.

                                  If you think about what a Web service
                                  is--it's really just a CGI/servlet/bean type thing that knows how
                                  to go off and change state someplace else. There's no reason
                                  why the content hoster and the content owner need to be the
                                  same entity. (If they always were, this whole Napster thing
                                  would be moot).

                                  Greg



                                  [1] http://www.aue.auc.dk/~kock/OHS-HT96/Documents/whitehead.html
                                  [2] http://www.tbtf.com/archive/1998-02-16.html#s05
                                • Dave Winer
                                  ... and a CGI/servlet-like behavior, there s no reason either have to be co-located on the same HTTP or other server. In fact, there s no reason that the
                                  Message 16 of 24 , Feb 12, 2001
                                  • 0 Attachment
                                    >>If you have a read/write Web protocol like DAV storing and object's state
                                    and a CGI/servlet-like behavior, there's no reason either have to be
                                    co-located on the same HTTP or other server. In fact, there's no reason
                                    that the behaviors need to be in the same language as the state access
                                    commands.

                                    So true!

                                    We've built our publish-and-subscribe system on this principle.

                                    http://www.thetwowayweb.com/soapMeetsRss

                                    Dave
                                  • Lucas Gonze
                                    ... You bet, though I stopped contributing when I realized how much I had to learn. Anyhow it s not my impression that XP is about factoring out a substrate
                                    Message 17 of 24 , Feb 12, 2001
                                    • 0 Attachment
                                      > Aren't you on the XP list?

                                      You bet, though I stopped contributing when I realized how much I had to learn.
                                      Anyhow it's not my impression that XP is about factoring out a substrate protocol of
                                      existing XML protocols.

                                      Is their goal as murky to you as it is to me? Can anyone say what differentiates XP
                                      without quoting the charter in full? Why isn't this SOAP 2.0 rather than a
                                      completely new thing? I suspect that megaCorp palace intrigue is behind some of the
                                      initial assumptions. Fear of SOAP as an MS wedge, maybe. That may be a reasonable
                                      business issue, but if so it should be discussed in broad daylight.

                                      Usecase:
                                      Block .Net adoption by preventing SOAP from becoming a dominant standard.

                                      Bleh.

                                      - Lucas

                                      > > It seems to me that protocol operations which are semantically
                                      > equivalent should be
                                      > > amenable to XSLT, which brings up the possibility of a third, underlying, XML
                                      > > protocol. Maybe SP for Substrate Protocol, or something.
                                      > >
                                      > Aren't you on the XP list?
                                      >
                                      > Greg
                                      >
                                      > To unsubscribe from this group, send an email to:
                                      > decentralization-unsubscribe@egroups.com
                                      >
                                      >
                                      >
                                      >
                                    • Dave Winer
                                      ... I saw that in the OpenCola whitepaper. http://www.opencola.com/software/octech.html SOAP in its current implementation is dependent on Microsoft s
                                      Message 18 of 24 , Feb 12, 2001
                                      • 0 Attachment
                                        >>Fear of SOAP as an MS wedge, maybe.

                                        I saw that in the OpenCola whitepaper.

                                        http://www.opencola.com/software/octech.html

                                        "SOAP in its current implementation is dependent on Microsoft's proprietary
                                        COM system."

                                        I ask for some proof of this, it goes right to the integrity of SOAP. As far
                                        as I know you can deploy SOAP with absolutely no Microsoft technology. We've
                                        done it, IBM appears to have done it, there are several independent SOAP
                                        implementations running in other platforms that don't *appear* to have any
                                        proprietary COM software involved.

                                        Dave
                                      • Joey deVilla
                                        ... D oh! ...serves me right for not yet being fully caught up on our implementation details for Folders (the project formerly known as Smart Folders), XPath
                                        Message 19 of 24 , Feb 12, 2001
                                        • 0 Attachment
                                          > > What I do know as that XRoad is based on the "object as document"
                                          > > philosophy. HTTP and XML were not originally designed as a
                                          > system for object
                                          > > serialization, but rather document transmission. Objects in the OpenCola
                                          > > network are treated as documents. As documents, they have
                                          > pathnames (hence
                                          > > the use of XPath), and pathnames give us a pretty simple
                                          > addressing scheme.
                                          > > Every peer on the network has its own URI, and services exposed
                                          > by that peer
                                          > > has a subpath of that URI.
                                          >
                                          > Most of this makes sense (document-oriented (or "resource-oriented" as W3C
                                          > types might say) protocol, using URIs for addressing), but URIs are for
                                          > addressing documents, not XPath. XPath is for addressing *inside*
                                          > documents, which you haven't really mentioned.

                                          D'oh!

                                          ...serves me right for not yet being fully caught up on our implementation
                                          details for Folders (the project formerly known as Smart Folders), XPath and
                                          XPointer. Protocol guru Chris Smith will be here in San Francisco in a day
                                          or two, and I plan to get him to fill me in on the full details. He's
                                          speaking at the O'Reilly P2P Conference, but hopefully you'll have a chance
                                          to meet him (and hopefully, I'll have a chance to meet you too).

                                          BTW, I'm still trying to get final and proper answers for Lucas' earlier
                                          questions from our protocol guys...

                                          ______________________________________________________
                                          Joey deVilla - joey@...
                                          Director of Developer Relations and Accordion Guy
                                          OpenCola [http://opencola.com]
                                          cell 415.725.5779 - office 415.437.6169
                                        • Clay Shirky
                                          ... This is really smart. ... This goes to *my* favorite rant-by-proxy, the LISP vs C paper from 1991. The heart of the argument was that everyone at MIT knew
                                          Message 20 of 24 , Feb 12, 2001
                                          • 0 Attachment
                                            > The Web eventually swept this very notion off its feet in response
                                            > to scalability issues. Dangling links--which became 404
                                            > errors--were the savior of the Web. Now anyone could add or remove
                                            > any information without having the transactional overhead of having
                                            > to keep everyone who's pointing at an anchor consistent.

                                            This is really smart.

                                            > Today, we have peer-to-peer architectures, and we have
                                            > the distributed object discipline ranting about how you can't
                                            > use the Web for decentralized computing because you can't
                                            > keep transactional coherency across a variety of distributed
                                            > nodes. Every time you tried to tell them about the
                                            > mechanism of inconsistency for scalability, you got an earful.

                                            This goes to *my* favorite rant-by-proxy, the LISP vs C paper from
                                            1991.

                                            The heart of the argument was that everyone at MIT knew that The Right
                                            Thing to do when an operation which had complicated state got a system
                                            interupt was to find a way to capture that state before returning to
                                            user mode. Meanwhile the ATT guys had designed Unix to simply fail and
                                            return an error code, distinctly not The Right Thing.

                                            But it was this philosophy -- essentially that perfection could be
                                            sacrificed for simplicity -- that led the ATT philosophy (exemplified
                                            in Unix and C) to spread like kudzu while the MIT philosophy (ITS and
                                            especially LISP) remained the MIT philosophy.

                                            http://www.jwz.org/doc/worse-is-better.html

                                            -clay
                                          • Joey deVilla
                                            Straight from OpenCola structured doc guru Chris Smith: === There is a difficulty with the question... do the URLs use fixed addressing based on domains and
                                            Message 21 of 24 , Feb 12, 2001
                                            • 0 Attachment
                                              Straight from OpenCola structured doc guru Chris Smith:

                                              ===

                                              There is a difficulty with the question...

                                              "do the URLs use fixed addressing based on domains and IPs, or do they
                                              support functional addressing a la Gnutella?"

                                              ...because the only real answer to it is 'yes'.

                                              What actually happens is closer to:

                                              "The URLs use non-fixed addressing based on domains and IPs, and they
                                              support functional addressing."

                                              A clerver can serve as a namespace location for other clervers, which dock
                                              underneath it. The lower clerver is reachable through the http:// of the
                                              upper clerver. However, the lower clerver may be in a position to
                                              participate in other namespaces as well, or to be a distinct location
                                              itself. In addition, IP addresses are only needed if the transport in use
                                              requires them. It may be that the lower level clerver is only reachable by a
                                              private protocol known to it and the upper clerver. An example of this would
                                              be email addresses; although the domain name system is used, final delivery
                                              of a message may be done completely independent of DNS and IP.

                                              Within each clerver, XPath addressing gives you functional addressing,
                                              letting you address messages that describe the recipient rather than
                                              identify them. However - docked clervers may provide an includeable summary
                                              of their internals for the upper clerver, so the scope of the XPath
                                              addressing is all available information in the current tree, which may
                                              include many clervers.

                                              ===

                                              Hope this helps. It certainly helped me!

                                              ______________________________________________________
                                              Joey deVilla - joey@...
                                              Director of Developer Relations and Accordion Guy
                                              OpenCola [http://opencola.com]
                                              cell 415.725.5779 - office 415.437.6169
                                            • Nick Lothian
                                              ... XP in what context? I m assuming this isn t eXtreme Programming we re talking about?
                                              Message 22 of 24 , Feb 12, 2001
                                              • 0 Attachment
                                                >
                                                > > Aren't you on the XP list?
                                                >
                                                > You bet, though I stopped contributing when I realized how
                                                > much I had to learn.
                                                > Anyhow it's not my impression that XP is about factoring out
                                                > a substrate protocol of
                                                > existing XML protocols.
                                                >

                                                XP in what context? I'm assuming this isn't eXtreme Programming we're
                                                talking about?
                                              • Lucas Gonze
                                                ... See XML Protocol Working Group at http://www.w3.org/2000/xp/Group/ From the charter: Today, the principal use of the World Wide Web is for interactive
                                                Message 23 of 24 , Feb 12, 2001
                                                • 0 Attachment
                                                  > XP in what context? I'm assuming this isn't eXtreme Programming we're
                                                  > talking about?

                                                  See "XML Protocol Working Group" at
                                                  http://www.w3.org/2000/xp/Group/

                                                  From the charter:

                                                  Today, the principal use of the World Wide Web is for interactive access to documents
                                                  and applications. In almost all cases, such access is by human users, typically
                                                  working through Web browsers, audio players, or other interactive front-end systems.
                                                  The Web can grow significantly in power and scope if it is extended to support
                                                  communication between applications, from one program to another. The purpose of this
                                                  Working Group is to create a simple foundation to support the needs of such
                                                  communicating applications.

                                                  A broad range of applications will eventually be interconnected through the Web. The
                                                  initial focus of this Working Group is to create simple protocols that can be
                                                  ubiquitously deployed and easily programmed through scripting languages, XML tools,
                                                  interactive Web development tools, etc. The goal is a layered system which will
                                                  directly meet the needs of applications with simple interfaces (e.g. getStockQuote,
                                                  validateCreditCard), and which can be incrementally extended to provide the security,
                                                  scalability, and robustness required for more complex application interfaces.
                                                  Experience with SOAP, XML-RPC, WebBroker, etc. suggests that simple XML-based
                                                  messaging and remote procedure call (RPC) systems, layered on standard Web transports
                                                  such as HTTP and SMTP, can effectively meet these requirements. Specifically, the XML
                                                  Protocol Working Group is chartered to design the following four components:

                                                  An envelope for encapsulating XML data to be transferred in an interoperable manner
                                                  that allows for distributed extensibility and evolvability as well as intermediaries.
                                                  A convention for the content of the envelope when used for RPC (Remote Procedure
                                                  Call) applications. The protocol aspects of this should be coordinated closely with
                                                  the IETF and make an effort to leverage any work they are doing, see below for
                                                  details.
                                                  A mechanism for serializing data representing non-syntactic data models such as
                                                  object graphs and directed labeled graphs, based on the datatypes of XML Schema.
                                                  A mechanism for using HTTP transport in the context of an XML Protocol. This does not
                                                  mean that HTTP is the only transport mechanism that can be used for the technologies
                                                  developed, nor that support for HTTP transport is mandatory. This component merely
                                                  addresses the fact that HTTP transport is expected to be widely used, and so should
                                                  be addressed by this Working Group. For coordination with the IETF, see below.
                                                • Dave Winer
                                                  They announced today that they re changing the name, btw. Dave ... From: Lucas Gonze To: Sent: Monday,
                                                  Message 24 of 24 , Feb 12, 2001
                                                  • 0 Attachment
                                                    They announced today that they're changing the name, btw. Dave


                                                    ----- Original Message -----
                                                    From: "Lucas Gonze" <lucas@...>
                                                    To: <decentralization@yahoogroups.com>
                                                    Sent: Monday, February 12, 2001 3:48 PM
                                                    Subject: RE: [decentralization] XP


                                                    > > XP in what context? I'm assuming this isn't eXtreme Programming we're
                                                    > > talking about?
                                                    >
                                                    > See "XML Protocol Working Group" at
                                                    > http://www.w3.org/2000/xp/Group/
                                                    >
                                                    > From the charter:
                                                    >
                                                    > Today, the principal use of the World Wide Web is for interactive access
                                                    to documents
                                                    > and applications. In almost all cases, such access is by human users,
                                                    typically
                                                    > working through Web browsers, audio players, or other interactive
                                                    front-end systems.
                                                    > The Web can grow significantly in power and scope if it is extended to
                                                    support
                                                    > communication between applications, from one program to another. The
                                                    purpose of this
                                                    > Working Group is to create a simple foundation to support the needs of
                                                    such
                                                    > communicating applications.
                                                    >
                                                    > A broad range of applications will eventually be interconnected through
                                                    the Web. The
                                                    > initial focus of this Working Group is to create simple protocols that can
                                                    be
                                                    > ubiquitously deployed and easily programmed through scripting languages,
                                                    XML tools,
                                                    > interactive Web development tools, etc. The goal is a layered system which
                                                    will
                                                    > directly meet the needs of applications with simple interfaces (e.g.
                                                    getStockQuote,
                                                    > validateCreditCard), and which can be incrementally extended to provide
                                                    the security,
                                                    > scalability, and robustness required for more complex application
                                                    interfaces.
                                                    > Experience with SOAP, XML-RPC, WebBroker, etc. suggests that simple
                                                    XML-based
                                                    > messaging and remote procedure call (RPC) systems, layered on standard Web
                                                    transports
                                                    > such as HTTP and SMTP, can effectively meet these requirements.
                                                    Specifically, the XML
                                                    > Protocol Working Group is chartered to design the following four
                                                    components:
                                                    >
                                                    > An envelope for encapsulating XML data to be transferred in an
                                                    interoperable manner
                                                    > that allows for distributed extensibility and evolvability as well as
                                                    intermediaries.
                                                    > A convention for the content of the envelope when used for RPC (Remote
                                                    Procedure
                                                    > Call) applications. The protocol aspects of this should be coordinated
                                                    closely with
                                                    > the IETF and make an effort to leverage any work they are doing, see below
                                                    for
                                                    > details.
                                                    > A mechanism for serializing data representing non-syntactic data models
                                                    such as
                                                    > object graphs and directed labeled graphs, based on the datatypes of XML
                                                    Schema.
                                                    > A mechanism for using HTTP transport in the context of an XML Protocol.
                                                    This does not
                                                    > mean that HTTP is the only transport mechanism that can be used for the
                                                    technologies
                                                    > developed, nor that support for HTTP transport is mandatory. This
                                                    component merely
                                                    > addresses the fact that HTTP transport is expected to be widely used, and
                                                    so should
                                                    > be addressed by this Working Group. For coordination with the IETF, see
                                                    below.
                                                    >
                                                    >
                                                    > To unsubscribe from this group, send an email to:
                                                    > decentralization-unsubscribe@egroups.com
                                                    >
                                                    >
                                                    >
                                                  Your message has been successfully submitted and would be delivered to recipients shortly.