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.'"

Comments

I'm 2 n00b

[FurtiveGlancer]

Someone please add the tag 'suddenoutbreakofcommonsense' to cover the licensing decision.

Re:I'm 2 n00b

[jhines]

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

Re:I'm 2 n00b

[SanityInAnarchy]

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.

Etch

[Anonymous Coward]

It must be running on Debian then :-)

GPL

[Anonymous Coward]

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

[Shadow-isoHunt]

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:GPL

[whatever3003]

Coward. Your priorities show a distinct lack of strength in your convictions.

Re:GPL

[superskippy]

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

[unix_core]

If it's not going to be kept free, then what significant benefits are there of it being adopted?

Re:GPL

[Anonymous Coward]

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

Re:GPL

[Teckla]

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:GPL

[Kroc]

Innovation.

Re:GPL

[ruin20]

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.

Re:GPL

[spidr_mnky]

Now it's my turn to get modded into oblivion for not being fond of the GPL. Sigh. If I had mod points, I would mod you down. Not for the entire post, but for this sentence alone. I do have mod points, but somehow a tick up or down wouldn't seem to get the point across.

Right now, the AC "troll" is at 2, and mister "now it's my turn" is at 5. I can't judge the inner intentions of the poster, but it looks like a cheap psychological trick to try to avoid getting the mod you anticipate.

I was tempted to mod the "troll" down, but I wouldn't think of modding down Teckla, because he gave some information and made an interesting point.

To reverse a common complaint around here, being in agreement with the group or factually correct doesn't make you insightful. Calling your score in advance doesn't change the content of your post, either, but makes you look childish.

Now mod me off topic.

Re:GPL

[bendodge]

Then go meet the folks who made the original Cisco/Linksys WRT54G!

Re:GPL

[Kjella]

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 pile because the cost/benefit ratio swings in favor of keeping it in-house.

Taking a huge proprietary application and adding a tiny bit of GPL is foolish, the GPL is best designed to work organically - it almost does what you need, you add the missing pieces and you have to distribute the changes with your binaries. Both suffer a bit from the "big change" problem, there's rarely anyone with incentive to do major changes, but the GPL suffers less because companies are often "forced" to release code they wouldn't have released if they didn't need to. In practise, I find that means there's a lot more GPL code I want to use - actual end-user applications that otherwise would have gone into the proprietary stack.

Try to understand that not everyone loves the GPL and not everyone that doesn't love the GPL is a troll. As a producer of proprietary software, it's no trouble understanding where your preferances lie. You get to keep all the good and important parts to yourself, you get a free toolbox and you get some others to do free (as in beer) maintenance. What's in it for me? Unless I start using anything pure BSD with source, little if anything. Maybe a bit better/cheaper software but usually the proprietary derivates will only use that to increase their margins. Does OS X being based on *BSD bring the BSDs much good, or is it just a bleak shadow with sub-percent market share? Has it reduced the prices of OS X?

Stating your preference for BSD because it helps proprietary development is an honest opinion. But when you take on the role of end-user, the GPL means I can use it any way I want, I have the source to modify it any way I want and as a company you can do as much proprietary in-house modifications as you want. The only thing you can't do is sell/distribute proprietary versions to *drumroll* end-users. Every OSS developer including Linus himself is probably an end-user to 100x as many projects as they develop, so we're all end-users. So when someone tries to say to end users "You shouldn't use GPL software because it's not really free." they're have either completely misunderstood, are trolling or is pushing someone else's agenda. It's extra freedom, but not extra freedom that'll do the end users any good.

Re:GPL

[kripkenstein]

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:GPL

[daffmeister]

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.

Re:GPL

[Timothy Brownawell]

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?

Re:GPL

[Ian Alexander]

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

[BrainInAJar]

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:GPL

[BrainInAJar]

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.

Re:GPL

[mrsteveman1]

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.

Re:GPL

[Cyclops]

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 your own, spoiled brats...

Re:GPL

[BrainInAJar]

Exactly, the license pissing and moaning between projects sucks, it'd be nice if every license offered exceptions for other OSI licenses

Re:GPL

[RAMMS EIN]

``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:GPL

[hondo77]

If you were highly respected, you'd have karma to burn.

Re:GPL

[Anonymous Coward]

I have seen slashdot crowd being very sensible. If you have some strong point and if you put it in sensible manner they don't mod you down. I hate these chickening out comments like "my turn to get modded down" etc. Somehow I feel its part of mod up scheme of the author of such comment.

Re:GPL

[Omnifarious]

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 features out faster than Open Source competitors. It was stupid and wrong.

The sad thing is, they all could've sold their stuff just fine as an Open Source solution. Most companies who bought from them bought an appliance that they wanted the company in question to just make work. That's a fine Open Source play, and I would've had a lot more respect for them had they actually done that.

Re:GPL

[ksd1337]

What a bunch of group-think sheep Actually, we're ponies who like Natalie Portman. And we hate sharks with frikkin' lasers attached to their foreheads.

Re:GPL

[Anonymous Coward]

Well thank you for taking the developpements of projects that want to, indirectly, encourage the spread of freedom, and using it to push a closed package.

Really, I'm sure we'd be lost without people like you.

Re:GPL

[moosesocks]

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 (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 author without his permission.

There is also a liability disclaimer that's pretty much standard for all code these days.

In many cases, the GPL is a huge liability. Corporations don't like that sort of liability, and also don't like an ideology being shoved down their throats. In contrast, the BSD license comes with no strings attached, and encourages developers to voluntarily contribute their changes back to the original project.

Re:GPL

[moosesocks]

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:GPL

[Cyclops]

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.

Re:GPL

[gnuman99]

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 of GPL software where it becomes your core.

Then of course you have BSD software that "just works" much better than any GPL software in its category - PostgreSQL. This is not to start some flamewar, but from my own *experience* it is true, Not all BSD software has a better GPL counterpart, though most do.

Re:GPL

[BrainInAJar]

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:GPL

[nahdude812]

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 provide such an exception, it's the place of project owners to provide such an exception for their project if they desire it.

FWIW, there's some awesome stuff in BSD, but personally I feel like if I'm providing my code to you, and you find it useful the least you can do is provide your changes to my code back to me so the rest of the world can benefit.

Re:GPL

[Hucko]

No, but it does make it traceable, a tenant of accountable. You may not know the person, but after a period of time you can get whether they are consistent in their posting. Are they informative, does other research into the issue back up their voiced opinion, are they logical, and do they seem to have an agenda?

The meme "What a bunch of group-think sheep." is becoming a indication of a group-thinker (a misnomer if there ever was). Just because a group of people think similarly, that makes them guilty of group-thinking? I think the inability to resolve conflicts with your own understanding and someone else's, as demonstrated by latching upon stereotypes, is a better indication of group-think sheep.

Re:GPL

[Anonymous Coward]

Actually I'd argue that Linuxes adoption is despite the GPL, not because of it. I'd call you on that, but this guy says it better.

Re:GPL

[Hucko]

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.

Re:GPL

[moosesocks]

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 business. this sort of practice isn't going to go away, and RMS is naieve to believe otherwise.

In a sense, the GPL forces RMS's personal view of "freedom" upon every project that even remotely goes near GPL'd code.

Similarly, were we not to have the LGPL, we wouldn't have projects like WebKit. There's no chance in hell that Apple would have open-sourced the UI toolkits that link to Safari, although they were willing to concede their modifications to the rendering core. Both Apple and the KHTML folks have openly admitted that they have enjoyed a mutually beneficial arrangement.

So perhaps the LGPL is the most conducive license to spur OSS development. It won't fall prone to greed and/or secrecy like the BSD license can, though it also won't scare commercial developers away, like the GPL is bound to do. Even so, it could do with being toned-down a notch.

Revisiting your time-limit proposal: Perhaps a compromise would be to ammend copyright laws so that a software product may only be copywritten if the developer supplies the Library of Congress with a full and complete copy of the source. Once the copyright term expires (the timeframe of which is a separate battle to be fought), or the software falls back to the public-domain, the Government releases the binaries and source to the public.

Re:GPL

[Hucko]

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 uproar would be rather spectacular.

And put everyone back to relying on the US Government! I think not! Not a terrible idea though... Something similar would put the license back into licensing...

Re:GPL

[Cyclops]

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:GPL

[Edam]

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

[Anonymous Coward]

Now it's my turn to get modded into oblivion for not being fond of the GPL. Sigh. - What is it here with lame strawman arguments like this? Geez.

Distributed computing.

[William Robinson]

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 through torture of designing a HA CORBA server)

Re:Distributed computing.

[gbjbaanb]

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

[bheer]

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.

Re:ZeroC's ICE

[Anonymous Coward]

Why do they hid their products pricing?

Re:ZeroC's ICE

[eric2hill]

Their standard quoted price is $10K for unlimited royalty-free distribution, but they are *VERY* willing to work with you to price the product correctly for your product. Don't discount that number if you have a commercial application. Negotiating a percentage of sales opposed to writing your own communications subsystem is really a no-brainer.

Re:ZeroC's ICE

[Anonymous Coward]

ICE is great. Just cant work out why there isn't more buzz about the product. It's cross platform, cross language and blisteringly fast.

He wrote this article on his PDA

[Anonymous Coward]

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?

[Timothy Brownawell]

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?

[RodgerDodger]

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?

[Timothy Brownawell]

Wouldn't that be "open spec" instead of "open source", with the open source reference implementation being a separate issue?

Re:Um, what?

[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.

Re:Um, what?

[BrainInAJar]

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.

[Anonymous Coward]

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.

Re:CORBA was shit. SOAP not much better.

[BotnetZombie]

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:CORBA was shit. SOAP not much better.

[RAMMS EIN]

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 standard is apparently complex enough that various implementations implement distinct subsets...meaning interoperability is hit and miss. And seriously...HTTP and XML? Horribly inefficient.

All I know about Java RMI is that it was a horrible pain to get everything set up right so that it would work...and even then, of course, it's _Java_ RMI, so I'm not sure it's the best choice if you don't want to prescribe a particular platform or object model.

What I think all these have in common is that they try to automagically solve a problem that can hardly be solved automagically. The premise, as far as I understand, of protocols like this is that they will let you exchange objects from your program with programs on remote machines, without you having to do any work on it. But, in practice, it's hard to decide how to go about that without specific knowledge of how these objects will be used. Specifically, objects tend to be part of a graph...which parts of the graph do you send over the wire? And then there's all the actually hard problems related to distributed programming...

As for the protocols, I've always thought it shouldn't be that hard. Lisp has this thing where you can read and write Lisp objects. Write it out and read it back in and you'll get an equal object. This is incredibly useful for many things, including debugging, but also makes it easy to envision a protocol for distributed computing - especially when you consider that Lisp programs also consist of Lisp objects.

On the other hand, Lisp's read-write protocol isn't the most efficient as far as parsing and transmission are concerned. So something could be gained there. And not all objects can be read back in - for some it would even be a Bad Thing if they could. And none of the harder problems (like which parts of the graph to send) have been addressed yet. On the gripping hand, I honestly feel it's already better than SOAP.

For the rest, I think the trick is to keep things simple. Think of what you want to send. Encode that using some simple, efficient encoding, and send it. Don't shoot for automagic, Just Works exchange of arbitrary program objects. Think about what you really need to send and send only that.

Oh, and don't draw in layers and layers of frameworks, please.

If this catches on then how long would it be

[Anonymous Coward]

before Microsoft releases their own just ever so slightly different version that was totally incompatible with any other version and made all its own tools work with their version only?

They will no doubt trumpet loudly their 'innovation' at the same time.

I hope Cicso license this in such a way that they could stop this sort of trick that M$ has played before on an 'open standard'

Hurrah!

[superskippy]

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 circumstances. The ones that have been designed to work under many circumstances (e.g. many programming languages, object oriented) are dismissed as being "too complicated".
3. A lot of the protocols are designed to advance someone's agenda, rather than be actually useful

Re:Hurrah!

[Anonymous Coward]

The great thing about standards is that there are so many to choose from

Bad Name

[Anonymous Coward]

Sorry, the name "Etch" is already taken (in context of computers): the current stable release of Debian has codename Etch.

Usually it's better to find a name that is not yet taken, at least not in the environment that the program lives in. It's much easier to search for, and avoids confusion.

Re:Bad Name

[abigor]

Do you honestly think Debian is even on Cisco's radar? Think again.

Less overhead, more messages - but ..

[terbo]

Will the big three instant messaging providers use it?

Less overhead means things like this will be easier.

The problem is if none of the popular services utilize the protocol, it will make no money.

(See: IRC & Jabber)

Re:Less overhead, more messages - but ..

[Anonymous Coward]

RPC over IRC and Jabber? Are you building a botnet? What are you talking about, you're not making any sense. The story was about messaging protocols, nothing about instant messengers.

Re:Less overhead, more messages - but ..

[terbo]

I don't want to get *too* into it, but I'm talking about how instant messaging makes *money*.

Re:Less overhead, more messages - but ..

[K. S. Kyosuke]

Might be, but you are totally off-topic here. This article is about doing this ober network, which has nothing to do with Instant Messaging, save for the fact that some information transfer is involved. IIRC, there are things like XEP-0072, that allow for application data messaging over XMPP, but these are also not exactly of interest to most Jabber users, and if they require server extensions, well, you'll be out of luck with using "popular services" }the public ones?] to transfer such data.

Cisco, Please use the LGPLv3 license.

[NZheretic]

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.

[Richard_at_work]

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.

Re:Cisco, Please use the LGPLv3 license.

[Anonymous Coward]

Don't assume that any license you choose for the libraries today will be good enough for everyone tomorrow. Unless, of course, it is the WTFPL.

Re:Cisco, Please use the LGPLv3 license.

[samkass]

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, considering how many rights v3 takes away from hardware manufacturers. They'd almost certainly want to keep things TiVo-style. IMHO, LGPLv2 does seem like a pretty good license for them, though, as a hardware manufacturer.

Ice?

[IamTheRealMike]

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.

Microsoft's Kerberos

[NZheretic]

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, 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:Microsoft's Kerberos

[Richard_at_work]

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

Re:Microsoft's Kerberos

[Timothy Brownawell]

"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:Microsoft's Kerberos

[Froqen]

A test suite wouldn't have helped. Win2k worked just fine with normal kerberos as a client and as a server. 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:Microsoft's Kerberos

[kjots]

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 of "freedom" in Slashdot article comments).

Most people simply would have no idea what to do with their lives without some figure of authority directing their actions. It's not that they're lazy or incompetent, it's just that we are social animals - what we do together has more meaning in our minds that what we do alone (trust me, I have spent enough time alone to know the truth of this statement).

Freedom these days feels more and more like abandonment - "You can do whatever you want with your life! Just go and do it somewhere else".

I would rather have too little freedom then too much. Any day.

Re:Microsoft's Kerberos

[Hucko]

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.

Imagination

[CarpetShark]

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 types from using things I worked on, but avoiding the GPL because you want corporations to have the ability to use public works it in works they then keep from the public is a VERY strange notion.

Re:Imagination

[Timothy Brownawell]

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.

Re:Imagination

[PopeRatzo]

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:Imagination

[CarpetShark]

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 :)

Re:Imagination

[Hucko]

Cisco? Google? Tivo?

Re:Imagination

[Edam]

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 license.

performance stats are probably misleading

[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) scheme stored in network byte order would beat SOAP in performance tests. And as features are added to answer the diverse needs of the various communities, I expect performance degradation in the whatever-comes-after-SOAP, too.

Re:performance stats are probably misleading

[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.


Yes, obviously. That's what they were measuring. SOAP's numbers in these tasks were far worse.

GPL - worst license ever

[timmarhy]

yeah lets create a license that will allow competitors to slaughter us if we choose to use a package with the GPL.

GPL is great for generic shit everyone would use, but if a company actually chooses to use it for custom kit they are nuts.

Let's see if it lasts

[JustShootThemAll]

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.

This is an improvement?

[Pedrito]

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:This is an improvement?

[smoker2]

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?

[AlXtreme]

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:This is an improvement?

[Pedrito]

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 was managing x calls a second", which would have been far clearer, in my opinion.

Re:This is an improvement?

[Anonymous Coward]

When I saw the suddenoutbreakofcommon sense tag I thought to myself people were appluading real protocols rather than the torrential downpouring of HTTP based nonsense we've seen lately complete with totally unecesary duplicative layering of data. (XML-RPC vs SOAP)

The difference in language use comes from the technology itself. SOAP has no way of sending one-way messages because of its layering over HTTP which precludes that possibility.

Round trips are essentially RPC calls in SOAP. Of course without having a specific context of comparision the numbers are meaningless.

Now all they need to do is throw in hooks for XA style transaction management and we'll be getting somewhere.

GPL is more protective

[GNUPublicLicense]

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 under the GPL and must be published.

Re:GPL is more protective

[gbjbaanb]

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 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.

As it is, the bosses at my company say 'sackable offence' to use GPL code, (which includes LGPL too even if its only kept built into a library).

Re:GPL is more protective

[Tweenk]

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.

Re:GPL is more protective

[psykocrime]

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 proprietary / closed-source code? Perhaps so... the business model may be different, and the risks different, but nonetheless, you can certainly profit from GPL'd software.

Re:GPL is more protective

[psykocrime]

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 that individuals and schools are allowed to do.

However, the GPL does forbid use of the code in *proprietary*
(non-free) software. The GPL does not allow adding any additional
restrictions to any program that includes the code. So any program
that incorporates the GPL-covered code, whether it be commercial,
academic, or avocational, must be released as free software. As a
whole, it must be released under the GPL (though you can put a more
lax GPL-compatible license such as X11 on the parts you write, if you
wish).

I think that people who say the GPL disallows commercial software are
probably saying "commercial" but actually thinking "proprietary". But
while they may understand the GPL rightly, lumping together commercial
software and proprietary software is a grave mistake. There is plenty
of noncommercial non-free software. There is also commercial free
software--and we want to encourage more.

I won't contribute to non-GPL or non-LGPL

[Anonymous Coward]

I only contribute to GPL or LGPL projects.

The reason is simple: I do it out of my hobby, not as a paid developer. I want to make sure that my creation cannot be exploited by anyone looking to make a quick buck - the software must stay free.

I've no quarrels with writing software for non-GPL or non-LGPL projects. They can hire me as a consultant for those (and spend real money).

What I want from Cisco...

[Midnight Thunder]

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 are almost doing a better job with their client, but they still need more information to add the firewall compatibility.

Soap robust? Hahahahaha.

[Anonymous Coward]

From the article:

"SOAP is a very robust standard, certainly."

These people are clueless. Soap/WS is the most brittle RPC protocol I've ever worked with.

Available now without a prescription smart !

[FromTheAir]

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 number of cognitive enhancers that are already available.

http://intelegen.com/nutrients/index.htm#Cognitive_Enhancers/ Galantamine, Huperzine, Vinpocetine Rock!

This is a short summary of each one: Memory Enhancement and Cognitive Function http://intelegen.com/nutrients/memory_enhancement_and_cognitive.htm/

Sorry wrong thread.

[FromTheAir]

Should have been http://science.slashdot.org/article.pl?sid=08/05/23/1956231

Re:A Word in Yiddish For Just This

[FurtiveGlancer]

Oi Vey, I think its "mishuggenah."

Oh but there is

[marxmarv]

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.

900 calls per second ?

[bytesex]

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:900 calls per second ?

[tuomoks]

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, optionally encrypted / decrypted even in rest, transaction / retry / reroute / audit / etc support without special coding, and so on.

Yes, systems as these already exist but unfortunately the code is still proprietary even the methods are 30+ years old. Maybe because some of those methods seem get patented lately or whatever, who wants (and have resources) to fight years in courts?

That's the LGPL

[argent]

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.

Sounds like Thrift

[bryanduxbury]

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?

Not just Etch that they're re-inventing

[Anonymous Coward]

There is also AMQP, the Advanced Message Queueing Protocol, which is fully open (both free and closed impls exist, but the spec is open), and provides a detailed on-wire specification.

See www.amqp.org, which redirects to a longer JIRA url.

"Those who do not understand FOSS are destined to re-invent it."