Slashdot Mirror


Cisco To Open-Source New Messaging Protocol

Esther Schindler writes "Do you use SOAP, CORBA or EJBs? You might want to take a look at Etch, writes James Turner for CIO.com. It's language-, platform- and transport-agnostic, and Cisco is planning to release it as open source. Certainly, it offers some technical benefits: 'In addition to a simplified configuration, Etch also promises less overhead over the wire, compared to SOAP. In a testbed environment where SOAP was managing around 900 calls a second, Etch generated more than 50,000 messages in a one-way mode, and 15,000 transactions with a full round-trip, company officials stated.' And the open source part? Cisco is in the process of deciding what license to use. 'The intent is to use a less restrictive license than GPL, perhaps Apache or Mozilla. This is to allow commercial developers to incorporate Etch into products without licensing issues. A final announcement on the licensing decision will be available in the next month.'"

6 of 118 comments (clear)

  1. ZeroC's ICE by bheer · · Score: 5, Interesting

    It'll be interesting to compare Etch to ICE, which is a GPL'd open-source, cross-language RPC toolkit (you can buy commerical licenses too). It's quite widely used by banks and is generally reckoned to be speedy.

  2. CORBA was shit. SOAP not much better. by Anonymous Coward · · Score: 3, Interesting

    All of these distributed technologies have been shit. CORBA was absolutely hell to develop with. Besides the runtime performance problems, development was always a huge hassle. It rarely just worked. J

    Java's RMI was slightly better. But again, the development overhead was huge. Generating proxy and stub classes becomes a chore really quickly, and debugging becomes a real challenge.

    SOAP was a little bit better than CORBA and Java RMI. At least writing the object layer code is a far more reasonable task. The performance, though, was complete shit compared to Java RMI and Corba. Whatever development time you saved initially in writing the SOAP interfacing code was instead spent trying to optimize what you had so that it wouldn't perform so fucking horribly.

    In some ways, I hope that Cisco can do better. But I really don't know if that's possible. It may just be the nature of the beast that these sort of technologies perform poorly, are slow to develop, and are often nothing more than a huge hassle.

  3. Cisco, Please use the LGPLv3 license. by NZheretic · · Score: 3, Interesting
    Releasing the implementation library under a LGPL license will still allow for the functionality to be incorporated ( via dynamic linking ) into any proprietary product. The LGPL will insure the availability of the source code and downstream legal reuse rights of Cisco's implementation to downstream recipients.

    The LGPL is the only license that will insure that at least that Cisco's implementation of the protocol can not be easily extended in an inoperative manner.

    Given the timespan that Cisco expects the protocol to be in use, version 3 of the LGPL is the best option.

  4. Ice? by IamTheRealMike · · Score: 3, Interesting

    Other than license, how does this compare to ZeroCs Iceï¼Y Does anybody know? I've played with Ice before and it's very well done, although I remain to be convinced of the value of remote object references in a distributed system.

  5. Re:Imagination by Timothy+Brownawell · · Score: 3, Interesting

    There's absolutely no ethical reason to choose a less restrictive license over the GPL. That depends on who you ask.

    The only thing the GPL restricts is the ability to restrict others. Funny thing is, it isn't possible anyway to "restrict others" in that fashion without their cooperation (buying/downloading your software). It restricts the choices available to the end user by causing certain products to not exist.
  6. Re:GPL by ruin20 · · Score: 5, Interesting

    I've never met a GPL code developer who released his code under GPL because he was forced. I support GPL because I believe if something is important it should be codified and that if you develop something for the community you should protect it for the community. But that doesn't mean that releasing something under an FOSS license without a "recontribute/openness" clause doesn't mean that there won't be active community development. Something built on and from sharing will always foster more sharing, it's an issue of principal.

    --
    Oh honey look... How cute... an angry slashdotter!