Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Cisco To Open-Source New Messaging Protocol 118

Posted by ScuttleMonkey from the would-you-like-to-see-my-etchings dept.
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.'"
This discussion has been archived. No new comments can be posted.

Cisco To Open-Source New Messaging Protocol More

Cisco To Open-Source New Messaging Protocol

Comments Filter:

  • I'm 2 n00b (Score:4, Funny)

    by FurtiveGlancer ( 1274746 ) <.moc.loa. .ta. .yuGhceTcoHdA.> on Saturday May 24, 2008 @06:30AM (#23526662) Journal
    Someone please add the tag 'suddenoutbreakofcommonsense' to cover the licensing decision.

    • Re: (Score:3, Funny)

      by jhines ( 82154 )
      I'm not fluent in the language, but there has to be a word in Yiddish for just this.

    • 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.
      Which also makes it incompatible with the GPL, I think.

      I figure, if you're going less restrictive than GPL, do it with a license that's compatible with the GPL. Otherwise, GPL or LGPL will allow open source developers to integrate it into (GPL'd) products without licensing issues.

  • GPL (Score:3, Insightful)

    by Anonymous Coward on Saturday May 24, 2008 @06:35AM (#23526682)
    Glad to see more and more companies moving away from GPL, understanding that it will only limit the potential adoption. As a highly respected registered member of the Slashdot community, I'm posting as AC as this post will very likely be modded troll.

    • Re:GPL (Score:5, Insightful)

      by Shadow-isoHunt ( 1014539 ) on Saturday May 24, 2008 @06:52AM (#23526764) Homepage
      You care too much about your karma - regardless of if your post is being sarcastic or not - say what you mean and mean what you say, stand behind it because we won't believe an AC anyways.

    • Re: (Score:2, Insightful)

      by whatever3003 ( 536979 )
      Coward. Your priorities show a distinct lack of strength in your convictions.

    • Re:GPL (Score:5, Insightful)

      by superskippy ( 772852 ) on Saturday May 24, 2008 @07:04AM (#23526810)
      Sorry to feed the troll, but the point of the GPL is not to increase adoption. Your absolutely right to say that other licenses will lead to greater adoption- but this is adoption by people who may take, take, take and not give back.
      Besides, it sounds like LGPL is what's needed in this case, anyhow.

      • Re:GPL (Score:5, Insightful)

        by Teckla ( 630646 ) on Saturday May 24, 2008 @07:37AM (#23526918)

        Sorry to feed the troll, but the point of the GPL is not to increase adoption. Your absolutely right to say that other licenses will lead to greater adoption- but this is adoption by people who may take, take, take and not give back.

        The company I work for sells closed source software. We also use some open source software (not GPL) in the product.

        We contribute back to the open source we use because it's more sensible. Adding the same features back in again and again would be counterproductive. We'd rather they get added to the open source project permanently.

        We have a blanket ban on using GPL'd source, though. We can't afford to GPL our entire 20 million line software stack, which would be the result of using even a tiny bit of GPL code.

        Try to understand that not everyone loves the GPL and not everyone that doesn't love the GPL is a troll.

        Now it's my turn to get modded into oblivion for not being fond of the GPL. Sigh.

        • Re: (Score:3, Insightful)

          by Kjella ( 173770 )

          We contribute back to the open source we use because it's more sensible.

          Well, the positive side is that you're contributing something. But I'd rather say that as "We contribute back to the open source we use only when it's more sensible". That means trivial fixes, basic features and other things that doesn't threaten your business and is cheaper to "outsource" the maintenance on. Any time it's major features, more specific layers to the business you're in that could make it easier to produce a software stack like yours, most decide to pile it up on their 20 MLOC proprietary pi

          • I suppose that's all well and true.

            However, the GPL is undoubtedly less free than the BSD license. You can do virtually anything with BSD-licensed code.

            If you take the time to read it [wikipedia.org] (it's about two paragraphs long in its entirety) , you'll notice that there are effectively two restrictions on using BSD-licensed code.

            1) You must retain the text of the BSD license somewhere in your product.
            2) You cannot advertise a product derived from BSD-licensed code in a manner that implies endorsement of the original

            • Re: (Score:2)

              by Hucko ( 998827 )
              So what we(end users) need is a compromise between BSD and GPL. Perhaps a time/version-delayed source release? After x years, or y iterations, the entire source must be released publicly. The creater is not responsible for use, bugs or any other miscellaneous claims. Thus, proprietory creators could still pimp their 'better' version and maintain in house benefits, while end users would enjoy the 4 freedoms and perhaps even be able to predict the likely cause (and thus a remedy) of their bugged experience.
              • Such a license would be extremely difficult, if not impossible to enforce.

                A compromise already exists in the form of the LGPL, which retains the restrictiveness of the GPL, but also allows closed-source code to link to it.

                Personally, I feel that LGPL should be the default license, rather than vice versa, given what a headache the linking cause can cause to commercial developers.

                This even causes problems for non-technology businesses who need to run proprietary software internally as a function of their busi

                • Re: (Score:2)

                  by Hucko ( 998827 )

                  It would be very difficult for enforcement of every project, but the truly successful benefiting projects that don't comply would eventually be compelled to just because of the outcry. If some niche market projects get by without being too obnoxious making a reasonable living, well, who cares? But when successful projects are being obnoxious as in the case of Apple to BSD... (speculation warning on both sides of the parenthesis!) if everyone was being told that Apple was ripping off poor little BSD, the upr

          • I only use BSD or similarly licensed software in my offerings as well. And generally I do give back all improvements to BSD that *make sense*. For example, a niche modification that only applies to my software doesn't really make sense to "give back" because no one wants it. But general bug fixes or features do make sense to give back.

            BSD hasn't improved as fast as GPL because when someone takes bits of BSD and uses it in their software, the BSD bits are NOT their core offering. This is completely opposite

        • Re: (Score:2, Interesting)

          by Ian Alexander ( 997430 )

          Sorry to feed the troll, but the point of the GPL is not to increase adoption. Your absolutely right to say that other licenses will lead to greater adoption- but this is adoption by people who may take, take, take and not give back.

          The company I work for sells closed source software. We also use some open source software (not GPL) in the product.

          We contribute back to the open source we use because it's more sensible. Adding the same features back in again and again would be counterproductive. We'd rather they get added to the open source project permanently.

          We have a blanket ban on using GPL'd source, though. We can't afford to GPL our entire 20 million line software stack, which would be the result of using even a tiny bit of GPL code.

          Try to understand that not everyone loves the GPL and not everyone that doesn't love the GPL is a troll.

          Now it's my turn to get modded into oblivion for not being fond of the GPL. Sigh.

          Is that really so? I thought the GPL only "infected" if you had to link against the GPL'ed code. Or is your codebase that... interconnected? And what about LGPL? Inquiring minds want to know!

        • I do not like companies like yours at all. I've worked in a couple, and the culture of them tends to be trying to put down any Open Source competitors and somehow claim your product is better when it isn't.

          One of these companies was basically a one-trick-pony that had one really neat technology and a bunch of non-GPL Open Source around it. They consistently bastardized the non-GPL Open Source and knowingly added huge security vulnerabilities for the sake of expediency and being able to have their feature

        • Re: (Score:1)

          by Edam ( 911039 )

          We can't afford to GPL our entire 20 million line software stack, which would be the result of using even a tiny bit of GPL code.

          So don't use it! I doubt the people who released it under the GPL care. If they had wanted you to be able to use this "community" source code in your closed-source product they would have released it under the LGPL.

          ...as the parent post suggested!

      • Re:GPL (Score:5, Interesting)

        by ruin20 ( 1242396 ) on Saturday May 24, 2008 @08:11AM (#23527068)
        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.
        • Then go meet the folks who made the original Cisco/Linksys WRT54G!

        • Re: (Score:3, Insightful)

          by daffmeister ( 602502 )
          That's because you've only met people similar to you. It's pretty normal to mostly encounter others of a like nature.

          However, there are plenty of groups out there who would quite happily take GPL code and add it to a closed source app, if the licence allowed them (and some that will do so even against the licence). Just because you haven't personally met them, doesn't mean they don't exist.
          • The issue isn't closed source apps taking GPL code, there's a real problem with open-source projects that can't take GPL code ( openbsd, opensolaris, etc )

            • Re: (Score:3, Insightful)

              by Cyclops ( 1852 )
              OpenBSD doesn't want to take GPL'ed code. They can, but they don't want to.

              They are perfectly fine to include it (and they do include GCC, for instance), and even link to it (but then the derived work will have to be GPL'ed and they don't want that).

              And some projects have the problem in the inverse direction. Linux can't benefit from dtrace except in design principles.

              Or even the fantastic ZFS.

              Oh well, I guess it's all down to the same premise: if you don't want/can't use it, then stop bitching and go write
              • Exactly, the license pissing and moaning between projects sucks, it'd be nice if every license offered exceptions for other OSI licenses

                • Re: (Score:3, Insightful)

                  by Cyclops ( 1852 )
                  Except that giving a "BSD exception" to the GPL would make the point of the GPL kind of moot.

                  The GNU GPL is there to make sure every single user of GPL'ed code has the 4 software freedoms.

                  The BSD's only make sure for the first recipient.

                  I'm not claiming the first is better than the second (although I believe so), just that their purposes are different enough to make it a childish request instead of coding your own version like a real man.
                  • FUD. Pure FUD.

                    A BSD exception to the GPL would look something like "must share under the GPL, unless the recipient project is licensed under: CDDL, BSD, APL, MPL, MIT, ... " meaning the whole project would have to be under that license, and only the BSD bits could be integrated in to closed source stuff ( the GPL drivers, whatever would have to be omitted from the closed integration )

                    • Re: (Score:3, Insightful)

                      by nahdude812 ( 88157 ) *
                      Under such a scenario, when the majority of source files in a BSD project contain a snippet of GPL code, and that project can no longer build without those GPL snippets, then the project is effectively GPL since the GPL code has become inseparable from the BSD code.

                      Or else the exemption allows the code to become relicensed as BSD when included in a BSD project - then I can start a "GNU/Linux/BSD" project which is simply a repackaging of regular GNU/Linux under a BSD license.

                      It's not the place of the GPL to

                    • Re: (Score:2)

                      by Cyclops ( 1852 )
                      I believe you're the one spreading FUD, since what you propose would in fact destroy the GNU GPL's objectives.

                      I think you never even read the GNU GPL or its FAQ and just believe blindly whatever some guy (whom you think you can trust) told you.

    • Re: (Score:2, Insightful)

      by unix_core ( 943019 )
      If it's not going to be kept free, then what significant benefits are there of it being adopted?
      • Sometimes people do good things without being forced to.

        In fact, forcing good deeds can in many ways be harmful.

        Apache seems to do pretty well for itself, despite not being under a restrictive OSS license.

    • Re: (Score:1, Funny)

      by Anonymous Coward
      Highly respected Slashdot Community member? There's an oxymoron somewhere, my friend.

    • Imagination (Score:3, Interesting)

      by CarpetShark ( 865376 )
      More and more companies moving away from GPL? That's a strange conclusion, considering that it's probably had the fastest growing mindshare an uptake of any software license, ever, and that GPLv3 is proving very popular already with new projects and migrations.

      There's absolutely no ethical reason to choose a less restrictive license over the GPL. The only thing the GPL restricts is the ability to restrict others. THAT is possibly a reason to avoid it, since, for example, I would like to prevent military

      • Re:Imagination (Score:4, Interesting)

        by Timothy Brownawell ( 627747 ) <tbrownaw@prjek.net> on Saturday May 24, 2008 @07:53AM (#23526972) Homepage Journal

        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.
        • Yes, but by choosing to use your product, they ARE agreeing to cooperate. That's the whole point of using copyright, which is where the agreement can be spelt out and enforced.

          But, Timothy, your signature is actually a much better argument against this :)

      • There's absolutely no ethical reason to choose a less restrictive license over the GPL.
        Now why you wanna go and bring ethics into this when people are trying to make more money than the next guy?

        Don't you know it's all about growthfaster?

        I bet we can name at least one company that's happy about this sudden outbreak of openness at the expense of GPL.

      • Re: (Score:1)

        by Edam ( 911039 )

        There's absolutely no ethical reason to choose a less restrictive license over the GPL.

        I'm not so sure about that. They may just not want to force other people to release their source code.

        But I would definitely say that if you want to release something like this to the open source community, then there is no justifiable reason not to at least use the LGPL. That would achieve the best of both worlds! It would ensure the source code remained community source code, whilst also allowing it to be used in proprietary, closed-source products without forcing those products to adopt an open source l

    • Glad to see more and more companies moving away from GPL, understanding that it will only limit the potential adoption. As a highly respected registered member of the Slashdot community, I'm posting as AC as this post will very likely be modded troll.

      Don't exaggerate.

      Sometimes the GPL is the right license, sometimes it isn't. Sometimes it increases adoption (Linux kernel), sometimes it doesn't.

      In this case, a messaging protocol, the natural license is indeed not the GPL. Better ideas are Apache, BSD, LGPL, etc.

      • Sometimes it increases adoption (Linux kernel), sometimes it doesn't.
        How do we separate the effect of the license from the effect of the development methodology? Or in this particular case, from the old BSD/ATT disputes?
      • Sometimes it increases adoption (Linux kernel), sometimes it doesn't." Actually I'd argue that Linuxes adoption is despite the GPL, not because of it. Linux was at the right place ( free, on commodity hardware ) at the right time ( BSD being sued by AT&T , commercial UNIX licensing fees skyrocketting to a ridiculous level ) and that's it.
      • That's a good point, also this is perhaps just reference code, it doesn't NEED to be under the GPL.

        People are free to write their own implementation under the GPL if they want to, just like they already do for a number of other protocols.
    • ``Glad to see more and more companies moving away from GPL, understanding that it will only limit the potential adoption.''

      I'm not sure that is actually the case. It would make sense if copyleft deterred some companies...but I could also see it actually attracting them. I don't know how the balance works out.

    • Re: (Score:2)

      by hondo77 ( 324058 )
      If you were highly respected, you'd have karma to burn.
  • Having developed many solutions using CORBA and SOAP, I welcome better solutions. Not sure though how it is going to resolve the problems we faced with CORBA and SOAP both?

    SOAP could be easily integrated over current HTML based networks without need to make hole in firewall. But it was pig slow and designing stateful services was painful.

    CORBA offered more technical challenges viz, complexity, version control, fault tolerance (not that a SOAP HA services is piece of cake, but I don't want anybody to go

    • Re:Distributed computing. (Score:5, Insightful)

      by gbjbaanb ( 229885 ) on Saturday May 24, 2008 @08:36AM (#23527204)
      Both those protocols suffer from 1 problem: bloat. The reason they're bloated and inefficient is because a committee decided how and what to add to the protocol once it was initiated, and we all know how well that works out.

      SOAP was a 'quick and dirty solution (by Don Box IIRC) to (apart from getting a job at MS :) ) transfer COM calls over a http tunnel instead of the usual DCE-RPC tunnel, and it worked well when you only wanted to send a request to an object. Obviously, it has to have a webserver on the other end which slows it down tremendously, and then they added support for all kinds of complex types and a large schema as well. I'm surprised it works at all after seeing the raw WSDL code!

      CORBA... designed by committee to do everything including transport kitchen sinks.

      Since I've been working in the industry there is a tendency for supposedly bright people to take something simple and 'make it a general purpose solution' or 'implement some framework features' which nearly always breaks it into a bloated POS far removed from the original, simple, easy to use, and effective solution.

      I welcome Cisco's new protocol, I don't care if it doesn't do everything I might possibly ever want to do, as long as it does the majority of my work quickly and simply. I can work around the edge cases myself, possibly even (gosh!) redesigning the way those edge cases work.

  • ZeroC's ICE (Score:5, Interesting)

    by bheer ( 633842 ) <{rbheer} {at} {gmail.com}> on Saturday May 24, 2008 @06:41AM (#23526708)
    It'll be interesting to compare Etch to ICE [zeroc.com], 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.

  • He wrote this article on his PDA (Score:4, Funny)

    by Anonymous Coward on Saturday May 24, 2008 @06:42AM (#23526712)

    looking at the width
    of the column in the
    article, and cio.com
    wonders why nobody
    visits their site
    and so they have to
    pimp their ad-laden
    site on Slashdot in
    a sure sign of des-
    peration. Click next
    to continue.

  • Um, what? (Score:3, Funny)

    by Timothy Brownawell ( 627747 ) <tbrownaw@prjek.net> on Saturday May 24, 2008 @06:43AM (#23526716) Homepage Journal

    How does one "open source" a protocol? There's no source to open, just a specification.

    *reads article*

    Ah, it's actually a set of libraries that use a new protocol.

    • Re:Um, what? (Score:5, Insightful)

      by RodgerDodger ( 575834 ) on Saturday May 24, 2008 @06:47AM (#23526738)
      You open-source a protocol by providing a specification with no attached IP rights, such as patents covering the protocol. A reference implementation kind of helps, too.

      • Re:Um, what? (Score:5, Insightful)

        by Timothy Brownawell ( 627747 ) <tbrownaw@prjek.net> on Saturday May 24, 2008 @07:07AM (#23526824) Homepage Journal
        Wouldn't that be "open spec" instead of "open source", with the open source reference implementation being a separate issue?

        • Re: (Score:2, Insightful)

          by Anonymous Coward
          Not all open specifications are freely licensed. The MPEG specifications are open, for instance, but you need to pay a license fee to use them.

          I think we really need to come up with a better term for this, or narrow the definition of an open specification.
    • you put it under the BSD license to increase adoption, like TCP.

      Or you release the specs with code that people can't just do what they want with, and then the only people that use it are you, and the people that pay you for your reference implementation, like NFS ( which is just terrible on linux, doesn't exist on windows, and only really works on the commercial UNIXes that paid Sun for their code )

  • CORBA was shit. SOAP not much better. (Score:3, Interesting)

    by Anonymous Coward on Saturday May 24, 2008 @06:48AM (#23526750)
    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.
    • You can use Spring to auto-generate proxy and stub classes for Java RMI. That way you don't need to write any boiler-plate code at all, very easy to use.

    • Re: (Score:3, Interesting)

      by RAMMS+EIN ( 578166 )
      I think the problem with all of these is that they consist of too much hype and too little sense. Also, a lot of them are horribly over-engineered.

      Taking SOAP as an example, because that's the one I know best. What you need is some way to communicate data to another party. What you get is something that does that, but in about the most verbose and latency-sensitive way imaginable. Yes, it's standards-based, which is a Good Thing, and it's human-readable, which is also advantageous.

      On the other hand, the sta
  • Just what the world needs! Another remote procedure protocol!
    Maybe Unix RPC, Corba, XML-RPC, SOAP, DCOM, DCOP and XPCOM were not enough already?
    Seriously, the problem in this space is that:
    1. Rather than working together on one RPC protocol that might not be 100% suitable for all uses, people just get the hump and start their own. Hello? These things are supposed to be interoperable! How does starting thousands of incompatible protocols achieve this?
    2. Some of the above protocols only work well under certain

  • Cisco, Please use the LGPLv3 license. (Score:4, Interesting)

    by NZheretic ( 23872 ) on Saturday May 24, 2008 @07:13AM (#23526844) Homepage Journal
    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.

    • Re:Cisco, Please use the LGPLv3 license. (Score:4, Insightful)

      by Richard_at_work ( 517087 ) on Saturday May 24, 2008 @07:21AM (#23526868)
      Sod the libraries, license them however you wish - give us full and unfettered access to the specifications so those of us that wish to produce a BSD licensed or Public Domain set of libraries can do so. Don't assume that any license you choose for the libraries today will be good enough for everyone tomorrow.

      • Microsoft's Kerberos (Score:2, Informative)

        by NZheretic ( 23872 )
        A purely public domain release of the specs will just lead to a repeat of the history of Kerberos. See Kerberos, PACs And Microsoft's Dirty Tricks [slashdot.org], along with almost every other protocol that Microsoft chooses to "extend" in an inoperable manner and lock out via both trade secret and incompatible patent licensing schemes.

        • Re: (Score:3, Insightful)

          by Richard_at_work ( 517087 )
          So? That's called 'Freedom'. I'd rather have too much of it than too little.

          • Re: (Score:1)

            by kjots ( 64798 ) *

            So? That's called 'Freedom'. I'd rather have too much of it than too little.

            No you wouldn't. You really, really wouldn't. Too much freedom means a pointless, uninteresting existence in which nothing you do has any real meaning. Too much freedom means an endless cycle of asking yourself "So now what?", again and again until the end of your life. Too much freedom means nothing will ever get done, because everyone else is using their over-supply of freedom to do things their way and arguing with anyone who disagrees with their way of doing things (sound familiar? There's a lot

            • Re: (Score:2)

              by Hucko ( 998827 )
              So, are you currently in a communist or extreme socialist country? If not, when are you planning to move? I personally disagree with your end statement. I'd rather have no idea of what to do with potential to do anything, than have someone limit what I can do based on their agendas and purposes.

        • Re: (Score:3, Interesting)

          by Timothy Brownawell ( 627747 )
          "Here's the spec, do whatever you want with it, but you can only use our name for it if you pass this huge test suite."

          • Re: (Score:3, Informative)

            by Froqen ( 36822 )
            A test suite wouldn't have helped. Win2k worked just fine with normal kerberos as a client and as a server [microsoft.com]. The problem was that if you wanted to deal with domain based groups you needed an extension, something that MSFT wasn't intrested in letting people have for free.

    • Re: (Score:2)

      by samkass ( 174571 )
      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 [interoperable] manner.

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

      Actually I don't see how it will do any such thing. People who get the code are free to implement whatever non-interoperable extensions they want as long as they publish the code. And Cisco will almost certainly not choose v3 of the LGPL, consi

  • Ice? (Score:4, Interesting)

    by IamTheRealMike ( 537420 ) on Saturday May 24, 2008 @07:29AM (#23526892)
    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.

  • performance stats are probably misleading (Score:1, Insightful)

    by Anonymous Coward
    I bet the test transactions were trivial, so the performance numbers would be dominated by the speed of parsing, validating, and dispatching the message.

    Not saying that SOAP is the best solution. It is XML-based, which everyone realizes is a mixed bag. In particular, validating XML parsers have to be huge to cope with the specification bloat. But why should everyone rush to accept such a fundamental infrastructure piece from a single vendor? Any messaging scheme based on the old TLV (tag, length, value
  • A new protocol, great!

    But will I use it? No, not before it has proven itself in the next few years. I'm not going to beta-test it and invest in a technology that might change consirably or disappear altogether.

    I'll check it out in about five years. It will be mature by then, or it will be obsolete.

  • Can someone explain how 900 calls generating 50,000 messages/15,000 transactions is better than what SOAP does? I'm not terribly familiar with how SOAP works, so please excuse my ignorance, but it seems to me that 2 messages per synchronous call and 1 for an async call would not only be ideal, but fairly straight-forward.

    • Re: (Score:2)

      by smoker2 ( 750216 )
      Way to go !
      Most people just don't RTFA, but you skipped a percentage of the words in the summary too !
      "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"
      15000 > 900
      Now do you see ?

      • Re:This is an improvement? (Score:4, Informative)

        by AlXtreme ( 223728 ) on Saturday May 24, 2008 @08:48AM (#23527270) Homepage Journal

        Most people just don't RTFA, but you skipped a percentage of the words in the summary too !
        "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"

        Flaming the GP isn't correct in this case, the summary is ambiguous. There is a difference between managing calls and generating messages, as a single call can generate multiple messages.

        A correct summary would have been to compare the amount of calls a second both SOAP and Etch can handle, or the amount of messages/transactions required for a fixed number of calls. But I think the PR-drone that wrote up the article did so knowingly to put SOAP in a bad light.

        Or are you simply being sarcastic? If so: WOOOOOSH!

      • Re: (Score:2)

        by Pedrito ( 94783 )
        Now do you see ?

        Actually, yes I do. It was, I suppose, the way it was worded, that made it confusing for me.

        My mis-interpretation was that where SOAP was making 900 calls, etch was generating 50,000 messages or 15,000 transactions from those 900 calls. The comparison, unless you really understand the mechanics underneath and what transactions vs. messages vs. calls means, seems very apples and oranges...

        I guess it would have made a lot more sense to say, "where SOAP was managing 900 calls a second, Etch wa
  • Indeed, I do not count the proprietary forks of pieces of open source software released on a not protective enough licence with "added closed and proprietary value" in them. The risk is to make the open source version crippled for proper use on purpose compared to proprietary forks. The companies or people using such naughty tricks are not a issue with the enforcement of fairness through the GPL licence: if you use a GPL piece of software, the GPL guaranties that any modifications, if distributed, remains u
    • Unfortunately, (and even if this is not true, but perception makes it so) if you use some GPL code in your project, your project must be released under the GPL.

      So commercial projects do not use GPL code at all, never, ever ever. Which is a shame as some of it is very good :)

      Now, if there was a licence that said "all the code in this package is GPL, if you use any of it you're bound to releases any changes you make to the code in this package only. Linked/compiled/merged/etc etc code that you add to it does

      • Re: (Score:1)

        by Tweenk ( 1274968 )

        you would see a huge uptake in OSS code in commercial projects
        That is exactly what GPL intends to prevent - proprietary software companies making profit from code released as free software. If you want to profit from code, write your own instead of convincing others to let you profit from their code. Or you can use LGPL libraries so that you can still profit from your code, while others can also benefit from changes you made to their code.
        • That is exactly what GPL intends to prevent - proprietary software companies making profit from code released as free software.

          No it isn't. The intent of the GPL is that the user of a piece of software should have the freedom to use, modify and/or redistribute it as he/she wants. Nothing stops you from charging money for - and making a profit from - GPL'd software. Red Hat - for example - make money every day from selling GPL'd code.

          Is making money on GPL'd code perhaps *different* from making money of of
      • So commercial projects do not use GPL code at all, never, ever ever.

        I think an RMS quote is appropriate here:

        -----Original Message-----
        From: Richard Stallman [mailto:rms@gnu.org]
        Sent: Friday, January 14, 2000 8:41 PM
        To: farber@cis.upenn.edu

        You will often hear people say that the GPL does not allow use of the
        code in commercial software. This is a subtle confusion.

        The GPL does not make any distinction between commercial and
        noncommercial software development. It allows businesses to do all
        the same things tha

      • Now, if there was a licence that said "all the code in this package is GPL, if you use any of it you're bound to releases any changes you make to the code in this package only. Linked/compiled/merged/etc etc code that you add to it does not need to be re-released, only changes to the code you received", then you would see a huge uptake in OSS code in commercial projects, they'd be happy to use it, and you'd be happy to see improvements released back, and users would be happy because we'd be reusing tons of code.

        Isn't that essentially what the LGPL is? As long as you leave some separate .so file that a user can build from some open source release and drop into your system, are your obligations to the LGPL not being met?

        Otherwise no closed-source software for Linux would exist because you couldn't legally link to bloody printf, Mozilla, xanim, and several other seminal multimedia products for Linux would never have been, and we'd be no further along than the HURD.

      • Now, if there was a licence that said "all the code in this package is GPL, if you use any of it you're bound to releases any changes you make to the code in this package only. Linked/compiled/merged/etc etc code that you add to it does not need to be re-released, only changes to the code you received",

        That's basically what the LGPL is about. If you want to add code but not release it you just make it a separate library.
  • Is for them to finally document the extensions that are using to IPSEC. If you don't have Windows and the Cisco router is using firewall requirements, then only MS-Windows is capable of connecting. This is not implemented for other platforms - at least this what I found with Linux and MacOS X. The guys working on vpnc [uni-kl.de] are almost doing a better job with their client, but they still need more information to add the firewall compatibility.
  • What is interesting is that there are many natural compounds available now. The drug companies spend a lot of money attempting to copy nature. They try to come up with a slight alteration that allows them to patent a "new" molecule that achieves the same effect as a natural compound.

    Common sense would have us just use the natural compounds but the Medical Industry is not interested because of the low profit margins.

    Here is a collection of easy to read technical articles and the related chemistry on a

  • In an environment where SOAP manages 900 calls per second, _anyone_ can score 50000 calls per second. No matter what your protocol is like.

    • Re: (Score:2)

      by tuomoks ( 246421 )
      I don't know about _anyone_ but it seems to be on right ballpark - measured! Also, the difference in memory usage seems to be huge - not as much but almost. And the code - using intelligent, configuration based build and delivery of messages only needs one common API to build a message, one common API to send a message and one event entry point to receive a message, always looks same, no playing with arguments, flags, whatever. And, of course, language, platform and communication/transport method agnostic,
  • Facebook has already done the initial work on Thrift, and lots of people are contributing. It's also already in the Apache Incubator on its was to becoming a full Apache project. So, why would I want to use Cisco's solution over Thrift?

Slashdot Top Deals

It isn't easy being the parent of a six-year-old. However, it's a pretty small price to pay for having somebody around the house who understands computers.

Close