Indigo is the managed communication stack that will ship with WinFX. It is the “V.Next” for ASP.NET Web Methods, .NET Remoting, Enterprise Services, System.Messaging, and WSE. Steve Swartz provides a conceptual overview of Indigo, walks through some code, and introduces you to his jackalope.
Introduction to Indigo
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Sheesh, about time they stop distributing exe files. Anyone know how to handle such files in Linux?
Nevermind, installing and running cabextract on the file fixed that.
Exactly what I was going to say. The video sounded interesting, but if they can’t be bothered to let me view it, they’ve lost my interest.
Sheesh, who the hell distributes video with some retarded exe wrapper? Just let us download the wmv or whatever the real format is.
It’s all a big Microsoft conspiracy to keep Linux users in the dark about their nefarious and diabolical plans.
It’s a poor security model. You have to download and run an executable in order to view some piece of data. Dumb dumb dumb.
Michael
WinFX, V.Next, Web Methods, .NET Remoting, System.Messaging, and WSE?
umm.. maybe it’s just me, but after reading that string of techo-marketing buzzwords, I don’t even want to RTFA.
V.Next just means “next version”, I guess.
WinFX is the programming framework which will launch with Longhorn, but will mostly (or wholly) be available for XP/2003 too.
.NET Remoting is the functionality in .NET that allows transparent object using and method calling across appd… ehm, networks.
System.Messaging is a more reliable message exchange method used in serious distributed systems (MSMQ actually)
WSE stands for Web Services Extensions, and it’s the protocol extensions made for Web Services because of limitations in the standard ones (on security, reliability etc.)
Indigo is Microsoft’s new stack that will supersede all these ways of communicating. It will be interoperable with Web Services, but probably not with .NET Remoting or System.Messaging.
It’s not really of great concern to most people (it just happens that it is to me), so you’re safe by not RTFA 🙂
Newsposts about Indigo are fun because most people don’t know what the hell it is or what’s it for, so they just switch into generic MS-bashing.
Please let this stand, I know the language is not required but it really does express the frustration that more than a few people feel regarding the blind usage of an inferior OS.
But this is not a place to express frustration, nor is it a place where “Windows = Inferior OS” should be considered an implication. This is OSNews, the news cover many operating systems, and this particular newspost is about Indigo. If you don’t care enough about Indigo to discuss it or actually learn what it is, there’s no problem! Just skip it.
I for one am very interested about it because I’m currenly working with .NET Remoting and want to know whether there are any design considerations I should make to help when I later move on to Indigo (and whether the move is worth the hassle in the first place)
You should watch this video if you are interested/working on distributed applications. It is not irrelevant to non-MS platforms, because Indigo will almost certainly be included with a future version of Mono.
Nice to see OSNews slowly turning into Slashdot Jr.
If you don’t understand Indigo, then don’t post.
He doesn’t “walk through any code”. I’m waiting for coded-up sessions to show this thing in action, yet a guy standing in front of a whiteboard, while interesting for a bit, gets boring because he’s not really showing us anything. Its a wasted opportunity.
Miguel De Icaza said he was disappointed by the indigo framework. He hasn’t spoken about this on his blog yet though.
The second video contained the code.
..second video, where? Got a link?
http://makeashorterlink.com/?A13B128DA
sweet, thanks.
There are surely new design considerations. For what I heard/read and code I saw, Indigo will replace most MS technologies for communication between servers and applications. This stack is thought to replace technologies like COM+/DCOM since it will allow communication between both different applications on same machines and different applications on different machines.
It will also be the basis for communication between MS technologies and thirdy-party ones. Based on web services, it will allow communication with clients like Java, Flash, PHP and so on. Moreover, Indigo will be mostly firewall-friendly, overtaking most limitations which DCOM(+) exposed. Indigo will ship two subsets of technologies for communication: first one has been planned to mostly enhance communications between Windows machines, expecially in environments like private LANs; second one has been planned to allow communication between mixed clients, expecially in restricted environments like Internet datacenters. A clear confirmation that the real battle is moving towards servers.
It’s a good set of technologies though the major disadvantage is it will require developers to switch technology again after they already did with .NET. It’s very weird that MS force their developers to switch again… it’s very unlikely for good planners like MS folks.
I can imagine production code based on that becoming complex really quickly. Nothing a little abstraction couldn’t hide, mind you.
I think on the whole, contracts are a Good Thing(TM) but in c#’s case, readability goes south a little bit.
Interesting though. To be fair at least network implementation details have been hidden by the indigo system.
I think so. Indigo throws DCOM out the window and replaces it with a much simplified technology that everyone can access, thats a pretty good situation be in for major third parties and other platforms, open and closed.
…I have to say this: it is (oh no, only will be) about time (in about 1.5 years) that MS realized some stuff others did before is actually usefull and should be done the MS-way also. Actually this is no surprise, since in so many similar cases MS has acted as a really slow fast-follower. So now they do the same as they always do, name it some wierd way, serve it as a world shaking innovation. On top of that, make some more stuff that’s breaking interoperability (i.e. with others, not with MS, but sometimes, ell, you know the drill), like as someone above said: protocol extensions made for Web Services because of limitations in the standard ones – oh, yeah, come on mama, right here.
Hell, and in all this, I see as much goodness and badness, since, just so you know, the most dev. work I do is with and under MS stuff. But it would be a very happy day when I could drop all the crap and go fully linux. Well, not to happen soon.
“Slowly? This place turned into slashdot jr. years ago when these dorks thought this place is called linuxnews.com or opensourcenews.com. ”
Are you serious? In this bastion of Windows fanatics where every week there’s a “Linux isn’t ready for the desktop” article you think this is some sort of haven for Linux users?? No, you must either be new here or simply not paying attention to the big picture.
Uh.. this is an OSnews site. They post articles about Operating Systems, good or bad. That is not what I am talking about.
I am talking about the comments on pretty much every article about Microsoft. Even if they are doing something good, it ends up with people finding a way to bash Microsoft.
This will be a core technollogy. Until now you had one kernel32.dll, user32.dll; but now, will you need one Indigo assembly for .NET 2, others for .NET 2.2, 3, etc.
“like as someone above said: protocol extensions made for Web Services because of limitations in the standard ones – oh, yeah, come on mama, right here”
That would be me (I’m posting from campus now so different IP). I should have clarified that said protocol extensions are, like Web services, agreed standards and not MS-specific extensions (WSE implements WS-Security, WS-Addressing, and WS-Policy, according to the download site).
This will be a core technollogy. Until now you had one kernel32.dll, user32.dll; but now, will you need one Indigo assembly for .NET 2, others for .NET 2.2, 3, etc.
Not really. Such technology won’t evolve the same way a small assembly could do. You will have Indigo core classes in Global Assembly Cache so everyone will use latest version. Plus, it is unlikely that they won’t be full backward compatibility…
As a pure game of theory, you could ship your application with other version of such core classes (for example, in the unlikely event that any incompatibility could happen) and place them in your BIN folder. That could work,in theory, but I believe that they wouldn’t received them same level of trust needed by such classes to correctly work when placed into GAC. This is not clear yet, but it would be very interesting…
However, we could state that (beside core technologies) the DLL hell affecting Windows systems is definitely behind our back…
No need to justify. MS provided extension to standard protocols since 2 years, at least. Such extensions address specific problems which has not been solved by standard specifications because there’s no agreement about it.
For example, AFAIK, Web services standard doesn’t include solutions for security and authentication and this is really slowing down implementation and development of web services. MS solved this by providing custom solutions so MS developers can use Web services to address real-world problems instead of endlessly waiting for a standard solution.