On Mon, Mar 15, 2010 at 2:38 PM, Gregory Collins <greg@gregorycollins.net> wrote:

Hi all,

Just subscribed, and after reading through the recent traffic on this
list in the archives I have a couple of quick comments.

First, and I've discussed this with Michael Snoyman at length in
private, I agree 100% with Chris Eidhof when he writes "I don't believe
that there could be one big framework for everybody." Even getting
consensus on what the prerequisites would be is basically impossible. To
quote Gour:

> Although it might be great framework, I'll be frank to say that
> Happstack with all technology that goes along is something which is
> either too complicated for me, not practical to be run on shared
> hosting (e.g. Webfaction), not documented properly and it belongs to
> 'noSQL' which is not for me at the moment.
>
> That's why I'm interested to discuss possibility to somehow
> consolidate Haskell's web frameworks nad provide something which is
> good for practical development, does not require VPS to be used, nice
> documentation etc.

A priori we've reached a fundamental disagreement about first principles
-- personally I couldn't give a rat's ass whether the framework I'm
using runs well on shared hosting, my focus is on being able to
efficiently service heavy loads in a production context. Obviously, on
the other side of the coin, being able to run in a CGI process hooked up
to Apache is really important to many people.

Michael wants to use YAML to define data models: more power to him, but
personally the idea of doing that makes me want to vomit. I'm not saying
that to disparage him at all, the idea isn't necessarily bad on its own
merits: it just isn't for me. Everyone has their own pet preferences.

I'm seeing a lot of energy being dedicated to standardizing interfaces,
which I suppose is an admirable goal, but to me it's putting the cart
before the horse: what's the point of having a standardized adapter when
there's nothing worth plugging into it, besides some middleware that
your framework should be providing for you anyways? Concentrating too
much on interop right now is a waste of time IMO - besides, on the level
that it's currently being discussed, that stuff is *easy*: making an
adapter between any two of the myriad different web stack
implementations (WAI, Happstack, Hyena, CGI, Hack, FastCGI, etc etc etc)
is trivial. I doubt there's anyone on this list who couldn't cook up a
WAI/CGI gateway in an afternoon.

We need pluggable *applications* (blog, CMS, RSS feed generation,
administrative panels, forum, wiki, caching, user management, etc) that
understand how to talk to each other --- expecting "plug and play"
compatibility between frameworks on this level, when there's no
consensus on the *primitives*, is a pipe dream. The first framework that
cracks this particular nut, in a way that makes it easy and pleasurable
for people to build web apps that perform, is going to gain a lot of
traction. Code talks.

Maybe I'm misunderstanding you, but your whole e-mail seems like a large contradiction. But firstly, I believe your premise is mistaken: we're not trying to "standardize interfaces" for the most part; it's true that WAI was such an approach, but that's not the focus of this thread. You claim that anyone could write an adapter between two interfaces; look at the code for hack-handler-hyena and you'll understand the folly of that sentiment. But more to the point: because of WAI, we don't *have* to write the adapter, and I don't see any substantive critiques of the WAI approach. (If there are, we can address them by fixing the WAI.)

Now, let me try to understand your point here: we need standardized interfaces for applications to communicate with each other, but we can't do that until we have the low level interfaces hammered out. On the other hand, you say that it's premature to try to standardize interfaces. And then you make it clear that the use case of many people (shared hosting) doesn't interest you at all; based on previous conversations, I believe this means that Snap will have *no* (Fast)CGI support. So where exactly are you hoping to create this platform from which everyone will build these great applications that snap together so well?

I think (correct me if I'm wrong) that everyone else here is in agreement that the goal should not be to create a great framework that will solve everyone's needs. The goal should be to create great libraries that can be used independently. For example, separating out happstack-server and happstack-state now provides two great libraries that someone can use as part of a completely different application stack.

I think that this approach is much healthier and productive than each of us trying to create the greatest snappable framework ever and hoping everyone else creates applications for it.

Michael