I remember there was an article about climbing Everest that was pretty high up on HN for a few days. It makes a lot of sense that it was popular now that I think about it since there's plenty of startup analogies to climbing Everest. Fall asleep because you need to "take a break" and you might never wake up. Just one of many interesting parallels.
The easier way to explain it is that Rails is not true MVC (true being defined by the original intention as described by Trygve Reenskaug for Smalltalk). True MVC is an architectural pattern based on the composite and observer patterns and is designed for synchronous apps. This is why Cocoa or Sproutcore are more like true MVC.
Rails is Model2, which is the web adapted version of MVC that is popular in server-side web dev.
Sproutcore doesn't sound much like Smalltalk MVC. In "Applications Programming in Smalltalk-80(TM):
How to use Model-View-Controller (MVC)" by Steve Burbeck, which describes how Smalltalk did it, it says:
In the MVC paradigm the user input, the modeling of the
external world, and the visual feedback to the user are
explicitly separated and handled by three types of object,
each specialized for its task. The view manages the graphical
and/or textual output to the portion of the bitmapped display
that is allocated to its application. The controller interprets
the mouse and keyboard inputs from the user, commanding the model
and/or the view to change as appropriate. Finally, the model
manages the behavior and data of the application domain, responds
to requests for information about its state (usually from the view),
and responds to instructions to change state (usually from the controller).
Looking at the Sproutcore diagram given in the article, it looks like that in Sproutcore input goes to the view, which then decides to pass it to the controller. In Smalltalk it sounds like input goes straight to controllers--views have no idea input happened unless a controller tells them about it.
It's not quite clear to me from the article, but it also looks like maybe the view gets what the information about what to display from the controller (which gets it from the model). In Smalltalk it sounds like the controller would tell the view that the view needs to update, and the view would talk directly to the model to get the data it needs.
In my opinion, there is no such thing as an MVC web application, if you are really serious about the term meaning something and not just being a pretty paint color to put on your framework. MVC has nowhere for a client/server to go, and that's the sort of detail that shouldn't be glossed over.
"Something like" MVC is certainly possible, but MVC directly is pretty much confined to something without a client/server in it, or a cloud, and also is pretty tightly coupled to Object Orientation, too.
I think it's better just to go with "separation of concerns" and "don't repeat yourself", and pretty much whatever comes out of the end of a design based on those things will be better than trying to jam MVC in a priori. Maybe it'll even be MVC, if that's what fits, but MVC isn't specially good, it's just one point of a myriad of points on the good-DRY/SoC frontier.
I'll grant that Sproutcore (and Cocoa for that matter) actually have a lot more in common with Fowler's Passive View (which I've usually seen implemented as a MVP rather than MVC) than the original Smalltalk MVC. But it surely has much more in common with the Smalltalk MVC than the Rails MVC. The only real difference is the composition of the pattern. The Smalltalk MVC is composed of Composite (View), Strategy (Controller) and Observer (Model), whereas the Sproutcore MVC is composed of Composite/Command (View), Mediator (Controller) and Observer (Model). They both manage state through a very similar three tier architecture.
Django does a good job of being realistic about what it is doing:
"If you’re hungry for acronyms, you might say that Django is a “MTV” framework – that is, “model”, “template”, and “view.” That breakdown makes much more sense." - http://docs.djangoproject.com/en/dev/faq/general/
The article also doesn't mention that MVC is also traditionally used to implement asynchronous UIs, which the web is not suitable for (e.g. there is no push mechanism for the model to update the views. Instead views must use AJAX to poll for updates to model.)
"G1 = A gateway that translates between XMPP and the protocol(s) used on a foreign (non-XMPP) messaging network"
I don't think my question was not vague at all. It just might be out of the ordinary. Most people are interested in XMPP client implementations. I want a pre-existing open-source project that would be a good first step towards building an XMPP gateway.
OK, I wanted to make sure that you were indeed asking for that. While you are correct that "gateway" is well-defined, most of the time I see it, it is misused or used vaguely.
So, I can help you out. The only library that I know of that is designed specifically for the purpose of implementing gateways is Thrasher Bird: http://developer.berlios.de/projects/thrasher/ (git at http://repo.or.cz/w/thrasher.git ). I am the lead developer of that library. While the "sales pitch" is that it wraps libpurple, it is actually designed so that the "gateway" part of the library is separate from the "protocol" part of the library, unlike every other gateway I've seen.
It's in Perl, and it's still a bit alpha-ish, but it is also exactly what you are looking for and in active development, so you'll have to decide whether that meets your needs.
If you're interested in more information or need help, contact me at jbowers@barracuda.com . Compiling may be a bit of a chore, but I've managed it on a couple of different Linux systems now.
Actually, now that I think about it, the only thing the C code is there for is libpurple support; it's all Perl and there's no compilation you'd need to do at all if you don't want to use libpurple.
