4 quadrants of Indigo

I just read John's recent post about Indigo, in which he refers to my last post. His real issue with the platform is that it does too much to hide the underlying asynchronous messaging that is really the core of the system. I feel the same way, about the async messaging but more strongly about the XML inside every message. John, in contrast, wants the XML hidden, arguing that Morts like him (his assertion not mine) don't want to see angle brackets, they should be left to Einsteins like me (again, his assertion not mine!). All of this made me realize very clearly that Indigo is striving to satisfy a broad range of requirements from a broad range of developers. I'm starting to think of those people and their requirements as fitting into four categories (yes, I could break it up more, especially between messages as individual entities vs. lists of method parameters):

1. sync, objects
2. sync, XML
3. async, objects
4. async, XML

John is in the 3rd group. I'm in the 4th group, though I can live in the 2nd group pretty easily too. Many people are in the 1st group, and that's the one that gets a ton of attention. Certainly at the Indigo SDR I attended earlier this year, just about every example worked that way. Indigo actually delivers XML for me and asynchrony for John, although maybe not as cleanly as we would like. The issue is that by presenting Indigo almost entirely in terms of the 1st group's interests, we run the risk of steering developers down what is often the wrong path. I think, though, that enough people are aware of the issues with that path that we won't fall into the same pit we've fallen into with distributed objects time and again. We should also note that people have built many successful RPC-based systems (including Windows, which uses MSRPC for a whole range of things). And if we don't like the service model on top of it because it is too RPC centric, the hooks are there to replace it with something we do like, which is more than we've ever had before.