Slashdot Mirror

Because that's what we needed. Another gaming network library that will once again abstract too many important things, be insufficiently tunable for different game genres, and impose an invasive obnoxious data un/marshalling scheme on every game object.

And have nothing whatsoever to do with anything profitable at Google, and so it will be abandoned a few weeks after it's published.

As a software engineer I can personally say that solving the issue mentioned above in generally trivial. All you have to do is add another abstraction layer. I have personally solved the issue my self by abstracting the actual playing of Ubisoft games to other entities. Getting the same experience is easy by using their excellent API. Specifically a one time call to the public method getDisappointment(); other useful methods are provided such as the public void method getMoneysWorth();

Because that's what we needed. Another gaming network library that will once again abstract too many important things, be insufficiently tunable for different game genres, and impose an invasive obnoxious data un/marshalling scheme on every game object.

And have nothing whatsoever to do with anything profitable at Google, and so it will be abandoned a few weeks after it's published.

Ice? ICE! This is ex-Ice...

Sir, turn in your geek badge at the door. We will mail your belongings later.

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.

If you're familiar with CORBA, and underwhelmed by SOAP, then you might like to check out ICE. It's an attempt to do CORBA "better" - in other words, without the designed by committee and everything bar the kitchen sink aspects that ruined CORBA. I was initially a little bit sceptical, but having played around with it for a notifications system I've become really impressed.

I contributed to TeRK while working on my MS at CMU.

The idea is to provide as simple of an interface to programming the robot as possible. You can write your own stuff directly on the hardware if you like (it's got a serial connection so it's easy to connect to). Or, you can take advantage of the layers of code and write something which runs on your PC... but still has access to things like values from the analog inputs and moving the motors -- all via 802.11. The project uses a lot of open source and the source code for all of the components is available. There is a lot of framework code written in C that runs on the Qwerk board itself, and it uses ICE to connect from the board to either a relay server or your PC. Then, for the people who don't like to program at all (or are just starting out), there is a lot of software, including a basic emulator of the board, mostly written in Java, that they can just run on Windows, Mac OS, or Linux.

During development, we took our PC app and a couple of Qwerks to a group of robotics hobbyists and they were floored by the kind of capability you can get for free with the Qwerk and all of the software that's already been written. Most of them wanted to find a way to incorporate the board into their own projects.

Anyway, the goal of the project is to have a wide appeal. I hope it can get a lot more people excited about what they can do, and all at a very low cost compared to other kits.

http://www.zeroc.com/ice.html is supposed to be Corba well done. Have you tried it?

I recommend Ice.

...I'm waiting for SOAP on ROAP to come out.

In the meantime, I'll use a sensible framework, such as ZeroC's Ice: http://www.zeroc.com/

(CORBA got more right than it got wrong.)

I have been using Ice for about a year now and can strongly recommend it as a middleware framework. They now support IceGrid which I have not tried but it appears much more elegant than Globus.

• How do entities advertise their properties/capabilities/preferences? How do entities get upgraded (Ice facets)? Does the framework specify different plugin models e.g. for avatars vs. edifices? Probably not.
• Are the laws of physics immutable? Provide defaults that can be overridden locally?
• How is "real estate" parcelled out? Idea: let anyone build anywhere and let users decide which version they wish to see at any given time. Various rating systems could provide "default" views. Slashdot? Metamoderation?!
• Can the experience degrade gracefully in the face of bandwidth issues?
• Is it possible to be agnostic wrt modeling, e.g. ray-tracing vs. triangles vs. ??? ? I have absolutely no experience in graphics, modeling, or game playing, so I don't even know what questions to ask.
• Can Grid computing be used to model particularly complex interactions?
• What large building blocks are available? ICE of course. What about FOSS game engines? CAD engines? Graphics engines (blender?)?
• Ideas for extensible widget toolkit: Avatars: stick figures, basic features. Edifices/landscapes: universe, star, planet, river, mountain, building, door, window, etc.
• What security precautions are needed? DOS seems like a possible threat in addition to cheating already mentioned.

That's very helpful. Thanks for the info. I know nothing about games or graphics, but I do know that there are some great FOSS tools available like ICE for distributed computing, blender for graphics, so maybe the time is ripe for such a project. Or maybe the idea isn't feasable. Time will tell.

Thanks to Moore's law embedded systems have grown up enough to use CORBA. I know this because I work on a project which uses CORBA heavily (at least in the TAO and JacORB incarnations). Since CORBA has strong typing, it is attractive to developers who depend heavily on typeness to provide checks in systems where no one likes bugs. And really, who wants to write another middleware to deal with distributed systems? I sure don't.

There is no disclaimer in the article so I think it is worth mentioning that even though Michi was CORBA for all intents and purposes for a number of years, his current employer provides a competitor to CORBA and Web Services. And, you guessed it, that product addresses each and every flaw he outlines in his article.

To be fair ZeroC and Michi do put their money where their mouth is by supplying Ice in source form, licensed under the GPL. Although I do not see them putting this in front of a body like the IETF or trying to get Ice bindings integrated into something like boost. This would really attack that one point in the article talking about having real systems implemented and having it in front of a standards body.

Now that I have put in the proper disclaimers, I have to say that having used CORBA the last 5 years I agree with Michi on every point. Our knowledge of POAs is just now getting to the point where we are comfortable using it in complex ways. We are only now willing to entertain the notion that we are actually using CORBA the right way. We have spent weeks reading, coding, recoding, testing and testing again to understand the spec and the real world usage. The learning curve is easily the steepest and tallest of any technology I have had to learn. I said "Amen" out loud when Michi mentions that people really screw up when they don't do it right.

Using CORBA as a real distributed object system is not possible unless the system is in a network that you have complete control over. Even now we use cumbersome workarounds to develop our system remotely because we can't use CORBA like we were supposed to. Thank you very little script kiddies for making us use firewalls every where! But if CORBA had been built with security in mind in the beginning at all, it would be vastly more useful then it is now.

And we have not moved on to things like Web Services precisely because we do not want to move away from type checking and we can see the train wreck associated to security. So we use CORBA the best we can (and we have been largely successful, BTW).

Now I am going back to checking whether try blocks have been done properly for the naming service code we have to implement because of the exact reasons Michi says most implementers need the CORBA naming service.

Thanks to Moore's law embedded systems have grown up enough to use CORBA. I know this because I work on a project which uses CORBA heavily (at least in the TAO and JacORB incarnations). Since CORBA has strong typing, it is attractive to developers who depend heavily on typeness to provide checks in systems where no one likes bugs. And really, who wants to write another middleware to deal with distributed systems? I sure don't.

There is no disclaimer in the article so I think it is worth mentioning that even though Michi was CORBA for all intents and purposes for a number of years, his current employer provides a competitor to CORBA and Web Services. And, you guessed it, that product addresses each and every flaw he outlines in his article.

To be fair ZeroC and Michi do put their money where their mouth is by supplying Ice in source form, licensed under the GPL. Although I do not see them putting this in front of a body like the IETF or trying to get Ice bindings integrated into something like boost. This would really attack that one point in the article talking about having real systems implemented and having it in front of a standards body.

Now that I have put in the proper disclaimers, I have to say that having used CORBA the last 5 years I agree with Michi on every point. Our knowledge of POAs is just now getting to the point where we are comfortable using it in complex ways. We are only now willing to entertain the notion that we are actually using CORBA the right way. We have spent weeks reading, coding, recoding, testing and testing again to understand the spec and the real world usage. The learning curve is easily the steepest and tallest of any technology I have had to learn. I said "Amen" out loud when Michi mentions that people really screw up when they don't do it right.

Using CORBA as a real distributed object system is not possible unless the system is in a network that you have complete control over. Even now we use cumbersome workarounds to develop our system remotely because we can't use CORBA like we were supposed to. Thank you very little script kiddies for making us use firewalls every where! But if CORBA had been built with security in mind in the beginning at all, it would be vastly more useful then it is now.

And we have not moved on to things like Web Services precisely because we do not want to move away from type checking and we can see the train wreck associated to security. So we use CORBA the best we can (and we have been largely successful, BTW).

Now I am going back to checking whether try blocks have been done properly for the naming service code we have to implement because of the exact reasons Michi says most implementers need the CORBA naming service.

Thanks to Moore's law embedded systems have grown up enough to use CORBA. I know this because I work on a project which uses CORBA heavily (at least in the TAO and JacORB incarnations). Since CORBA has strong typing, it is attractive to developers who depend heavily on typeness to provide checks in systems where no one likes bugs. And really, who wants to write another middleware to deal with distributed systems? I sure don't.

There is no disclaimer in the article so I think it is worth mentioning that even though Michi was CORBA for all intents and purposes for a number of years, his current employer provides a competitor to CORBA and Web Services. And, you guessed it, that product addresses each and every flaw he outlines in his article.

To be fair ZeroC and Michi do put their money where their mouth is by supplying Ice in source form, licensed under the GPL. Although I do not see them putting this in front of a body like the IETF or trying to get Ice bindings integrated into something like boost. This would really attack that one point in the article talking about having real systems implemented and having it in front of a standards body.

Now that I have put in the proper disclaimers, I have to say that having used CORBA the last 5 years I agree with Michi on every point. Our knowledge of POAs is just now getting to the point where we are comfortable using it in complex ways. We are only now willing to entertain the notion that we are actually using CORBA the right way. We have spent weeks reading, coding, recoding, testing and testing again to understand the spec and the real world usage. The learning curve is easily the steepest and tallest of any technology I have had to learn. I said "Amen" out loud when Michi mentions that people really screw up when they don't do it right.

Using CORBA as a real distributed object system is not possible unless the system is in a network that you have complete control over. Even now we use cumbersome workarounds to develop our system remotely because we can't use CORBA like we were supposed to. Thank you very little script kiddies for making us use firewalls every where! But if CORBA had been built with security in mind in the beginning at all, it would be vastly more useful then it is now.

And we have not moved on to things like Web Services precisely because we do not want to move away from type checking and we can see the train wreck associated to security. So we use CORBA the best we can (and we have been largely successful, BTW).

Now I am going back to checking whether try blocks have been done properly for the naming service code we have to implement because of the exact reasons Michi says most implementers need the CORBA naming service.

I'm thinking of decoupling the modules physically so that, even if one crashes/becomes unstable (say, the distributed communication module encounters a segmentation fault, has a memory leak or a deadlock), the others remain alive, detect the error, and silently re-start the offending 'module'.

AFAIK gSOAP doesn't come out of the tarball with fail over. Also, why waste all that CPU encoding and decoding XML if you can avoid it? And HTTP is a crappy protocol unless you are using it for hypertext. You might consider ICE. You can also optimize communications down to in-proc function calls when critical by taking advantage of the co-location optimization feature. Try that with web services!
As far as not crashing, minimize the use of naked pointers and use RAII and C++ becomes a very high level language.

I started writing an application in C++ a few months ago. I have similar goals, specifically stability and data integrity. Obviously the language doesn't really help with those two goals, but a strong flexible design combined with a large test-case framework is a good place to start.

As for the middleware, I've been looking at the Ice middleware library from ZeroC. It can be commercially licensed for closed-source development, or used freely in an open-source project.

From the documentation, their protocol looks like it's very well designed, and very full-featured. I also like their grid, proxy, and batch capabilities. All in all, Ice looks much better than CORBA and far easier than trying to roll my own middleware.

Does anyone reading Slashdot have any hands-on experience with Ice? I'd appreciate any comments/advice/email you care to share on this topic.

If you consider CORBA check out TAO (http://www.cs.wustl.edu/~schmidt/TAO.html), it is a reliable open-source implementation that is widely used. You can get commercial support for it from OCI (http://www.theaceorb.com./

If CORBA is too heavyweight for you take a look at ACE (http://www.cs.wustl.edu/~schmidt/ACE.html). ACE is an open-source portable framework that is used within the TAO real-time CORBA. It allows you to write portable networked applications in C++ but is a lot smaller than CORBA as it does not implement the ORB etc. Several companies use ACE as a lightweight middleware as it has a very permissive license. You can get commercial support for it from Riverace (http://www.riverace.com/).

If you're aiming for performance you might check out ICE (http://www.zeroc.com./ ICE is available under the GPL and commercially and is a really fast middleware that is not CORBA but is portable between several languages.

All options provide you with a good framework to develop reliable and maintanable code.

Although I've never had reason to do this myself, I've heard people recommend cross-compiling code onto a PPC or SPARC64 platform and then fuzz your program on those platforms to look for bugs that might not have shown up on x86.
As for your question about CORBA, look into IceC++. I read about it somewhere and it sounded cool :)

Please mod the parent up!
AJAX is a very bad stack technically. Here are the steps for google to build a platform that doesn't suck:

1) Kill HTTP/XML for RPC. Buy http://www.zeroc.com/ and open-source ICE.
2) Kill JavaScript. Throw manpower behind a FAST, multi-language, multi-platform, open VM. Java is not it for numerous reason. Mono would be the best current candidate technically. Perhaps Parrot. There should not be a war between Ruby, Python and C#, if the platforms are united in VM.
3) Kill HTML. Pick a widget set and make sure it works flawlessly on the before-mentioned VM. Then extend it to create nice sexy controls.

By the way MS is doing all of this with .NET already...

PS. Good alternative to CORBA is ICE (http://www.zeroc.com/ice.html), which is basically the same thing as CORBA, and founded by one of the CORBA gurus. ICE has much better C++ mapping, and lots of other nice features.

Hope this helps!

CORBA is ok, but it definitely suffers a lot from design by committee. Michi Henning one of the main people on the OMG architecture board has , with others formed a seperate company (zeroc) where they've attempted a more focused approach to the issues CORBA was designed to solve. Their site makes very interesting reading. Particularly the section below :

http://www.zeroc.com/iceVsCorba.html

In some sense they have. The middle-ware that did all of the heavy-lifting is avialable under the GPL from ZeroC

The problem with games is that they often need both styles of comms, synchronous twoway RPC as well as event-style pub/sub comms. Any middleware that supports one but not the other is likely to be hard to use. We designed Ice such that it can do both well. (You can look at Chapters 18 & 25 of the doc for details.)

Basically, Ice supports the usual twoway, synchronous RPC, as well as oneway calls (which don't require a reply from the server), and UDP. The protocol is designed such that it is possible to build very efficient message switches for event distribution.

BTW, I used to work at DSTC with the guys who built Elvin -- it's a fine piece of work and well woth a closer look.

Cheers,

Michi.

See this link for a properly printable version.

You can find a PDF version of the full article (exactly as printed in the magazine) here.

Cheers,

Michi.

KParts is rather specialized for its use within KDE. If you want an alternative to CORBA, I'd strongly consider ZeroC's ICE. It was designed by a group of people to be both more powerful than, and much simpler than CORBA. Especially, read their comparison between CORBA and ICE, and how ICE addresses the weaknesses of CORBA.

Perhaps you find this article interesting: "A New Approach to Object-Oriented Middleware". This article appeared in the IEEE Internet Computing magazine, and compares Ice with CORBA.

Perhaps you find this article interesting: "A New Approach to Object-Oriented Middleware". This article appeared in the IEEE Internet Computing magazine, and compares Ice with CORBA.

You can find Ice at this page. From what I've seen, it's everything CORBA should have been, and easy to use to boot!

Have you looked at ICE? The developers are long time CORBA gurus who set out to fix some of CORBA's problems. It looks quite promising but then I haven't used it in anger.

You should have a look at zeroC. I haven't used it but have had very good reports about it. Plus the licensing is purely volume based or free if your product is open source.

However, I've also had a bit of experience with the Java mapping. Let me tell you, the Java mapping is just beautiful. If you can find an excuse I'd recommend working with it a bit if for no other reason than to experience what a good CORBA mapping can be like

The Python mapping is also very good. In both these cases, the people really understood both the language and OOP.

I don't know what those who wrote the C++ mapping were thinking

It's a long and sordid story.

My first reaction to seeing the C++ mapping, as a fresh graduate, was that clearly it was written by C programmers who just didn't understand the whole "object orientation" thing yet.

In part, I was right. The C++ mapping was deliberately designed to preserve binary compatability as much as possible with the C mapping. Back in the early 90s this probably appeared to be necessary. I've never heard of anyone needing this *ever*, but that's the official reason.

When the mapping was standardized, there was the mapping we ended up with, and a competing alternative that was OO, intuitive and just about as good as the Java mapping. But, the C style "non-OO" mapping was perceived as "more efficient" for some reason, there were a lot of politics, the company who designed the OO mapping collapsed IIRC, and some large and influential vendors had already implemented the "non-OO" one.

So that's how we got here. I did go to the trouble of writing a code generator that was intended to "wrap" the standard C++ mapping code in a nice OO layer (and that used strings and vectors!). That was OK, but I underestimated the number of gotchas involved in the C++ mapping. Trying to encode every single silly arbitrary rule was a nightmare. Basically, I wouldn't try that ever again. But who cares, I've got the Python mappings and Fnorb, right? ;)

Now, if you want to get some idea of what a good C++ mapping might look like, take a look at ICE from ZeroC

Disclaimer: I *don't* work for ZeroC, nor do I have any interest financial or otherwise in them. I have worked with some of their employees in the past.

ICE is basically CORBA redesigned from the ground up without the cruft, and with a decent C++ mapping. It's available for C++ and Java, and free for non-commercial use. It's being used as the underlying communications engine for a massively-multiplayer game, "Wish" by MutableRealms.

I've always thought these multiplayer online games would be an interesting field for people who know something about distributed systems, as the first generation of such games clearly didn't have much of a clue about how handle this aspect very well at all.

Um, CORBA sucks so much ass its not even funny. Its one of the worst designed-by-committe standards ever produced. The C++ mapping is completely non-standard and retarded. Ugh...

See ICE for a CORBA replacement that doesn't suck.

You might want to have a look at Ice from ZeroC. Ice is a new OO middleware platform that is IMO far superior to CORBA. Ice is GPL'd. For a comparison between Ice and CORBA, have a look at this page.

You might want to have a look at Ice from ZeroC. Ice is a new OO middleware platform that is IMO far superior to CORBA. Ice is GPL'd. For a comparison between Ice and CORBA, have a look at this page.