struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject RE: MVC specification Request
Date Thu, 25 Apr 2002 05:54:12 GMT

On Wed, 24 Apr 2002, Sandra Cann wrote:

> [snip]
> Which is exactly why I propose a specification needs to be defined. I am not
> proposing there be only one implementation :).
> > If MVC becomes a spec, does that mean Struts is the only
> > one that does it according to the spec,
> No, of course not. I'm was proposing it be an open source reference
> implementation.

Indeed, that is the whole point of the JCP -- to create specifications for
portable Java standards that can be implemented in more than one way.
Trying to "bless" an existing single implementation of some concept is
pretty unlikely to get accepted as a JSR -- let alone accepted as a viable
specification even if it were to be approved.

> > and all of the other ones have to
> > suddenly change (perhaps drastically) to be a correct
> > implementation of MVC?
> It is a process. The expert team would be comprised of experts from various
> MVC projects to arrive at a spec. This is a process that might take a year
> or two. So it would not be a sudden change for anyone. We're talking about a
> community process - in other words various MVC projects aligning on a
> specification.

There is also zero chance that any existing framework would get adopted
without change.  Switching package names to* would only be the
beginning of such a transition.

> > but I sure would hate to be "forced" (so to
> > speak) to rework my framework just so that developers would consider it a
> > "compatible" MVC framework.
> There is no forcing. Whether a MVC implementation chooses to be compliant
> with a spec would be entirely their choosing.

Which is the whole point.  The fact that JSP is a standard, and that there
are multiple competing (but compatible) implementations, certainly didn't
kill all of the non-JSP templating solutions in the world.  It does,
however, raise the bar for explaining why a non-JSP templating solution is
better enough to be worth paying attention to -- just saying "because JSP
sucks" isn't likely to win many converts :-).  For evidence, go to and do a search for jobs that require JSP skills, versus your
favorite non-JSP technology.  Not all (or even many) of those companies
are stupid morons that don't have a clue.

> The ultimate goal here from my perspective is to continue strengthening Java
> and create less architecture fragmentation. The more united Java is at the
> architecture level the stronger Java is in the playing field with .net.

As I mentioned to many people at JavaOne this year, "when is Struts going
to become a JSR" was the most popular question to me at the 2001 JavaOne
conference.  In reality, the answer is "never" -- if we consider the
endgame to be "standardize Struts in exactly its current form."  If,
instead, we are interested in standardizing an MVC-based architecture that
can rationally be implemented by multiple products and packages (most
likely including Struts), what that takes is someone who has time to lead
a JSR effort to accomplish this goal.  My observation of many JSRs over
the last few years is that the spec lead role is pretty much a full time
job -- it's a combination of technical skills at crafting a viable
standard without over-constraining the implementation, plus the political
skills to gain consensus among expert group members (who often have their
own implementations of something in the same space as the JSR under
consideration, or they wouldn't have been "experts" in the first place).

I think the web application architecture space is approaching the maturity
where it makes sense to start thinking about standardization.  I think
that Struts is a very popular de facto standard in this space.  I also
think that there's room to figure out whether a common API for the
controller and model parts of such a framework can be standardized -- the
view part is already being take care of between JSTL and Faces in the Java
standards world.  The task of making this kind of thing happen is a pretty
significant investment in time and effort, however.

> --
> Sandra


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message