Slashdot Log In
Cisco To Open-Source New Messaging Protocol
Posted by
ScuttleMonkey
on Sat May 24, 2008 06:21 AM
from the would-you-like-to-see-my-etchings dept.
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.'"
Related Stories
[+]
Cisco To Buy Jabber 66 comments
Danny Rathjens writes "In the continuing trend of big companies buying out small companies with open source products, Cisco has announced that they are buying Jabber. The press release doesn't really talk about the open source aspect of Jabber, and Jabber's website doesn't mention the news yet. I'm sure the question many of us have is whether Jabber's open source status will be changed in any way due to the purchase."
Reader Eddytorial had this to contribute: "eWEEK offers a good look into how Jabber's messaging client will fit into Cisco Systems' overall 'presence' strategy in its market wars with Avaya, Microsoft, Nortel, and others. Cisco, which already had a basic instant messaging option, but one that didn't scale for an enterprise nearly as well as Jabber's, has just about everything else in place." It's also worth noting that Cisco open-sourced Etch in recent months.
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
I'm 2 n00b (Score:4, Funny)
Re: (Score:3, Funny)
GPL (Score:3, Insightful)
Re:GPL (Score:5, Insightful)
Parent
Re: (Score:2, Insightful)
Re:GPL (Score:5, Insightful)
Besides, it sounds like LGPL is what's needed in this case, anyhow.
Parent
Re:GPL (Score:5, Insightful)
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.
Parent
Re: (Score:3, Insightful)
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
Re: (Score:2, Interesting)
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!
Re:GPL (Score:5, Interesting)
Parent
Re: (Score:2)
Re: (Score:3, Insightful)
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.
Re: (Score:2)
Re: (Score:3, Insightful)
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
Re: (Score:3, Insightful)
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.
Re: (Score:3, Insightful)
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, Insightful)
Imagination (Score:3, Interesting)
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)
Parent
Re: (Score:2)
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:2)
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.
Re: (Score:2)
Re: (Score:2)
Distributed computing. (Score:2, Interesting)
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)
SOAP was a 'quick and dirty solution (by Don Box IIRC) to (apart from getting a job at MS
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.
Parent
ZeroC's ICE (Score:5, Interesting)
Re: (Score:2, Insightful)
He wrote this article on his PDA (Score:4, Funny)
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)
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)
Parent
Re:Um, what? (Score:5, Insightful)
Parent
Re: (Score:2, Insightful)
I think we really need to come up with a better term for this, or narrow the definition of an open specification.
CORBA was shit. SOAP not much better. (Score:3, Interesting)
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.
Re: (Score:3, Interesting)
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
Hurrah! (Score:2)
Maybe Unix RPC, Corba, XML-RPC, SOAP, DCOM, DCOP and XPCOM were not enough already?
Seriously, the problem in this space is that:
Cisco, Please use the LGPLv3 license. (Score:4, Interesting)
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)
Parent
Microsoft's Kerberos (Score:2, Informative)
Re: (Score:3, Insightful)
Re: (Score:3, Interesting)
Re: (Score:3, Informative)
Ice? (Score:4, Interesting)
This is an improvement? (Score:2)
Re: (Score:2)
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)
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!
Parent
Re: (Score:2)
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
What I want from Cisco... (Score:2)
Re: (Score:3, Insightful)
Re: (Score:2)
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:2)