avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject [RT] dot.Net And Avalon
Date Wed, 26 Mar 2003 17:53:36 GMT
Don't stone me for mentioning a Microsoft product, but I just sat
through a meeting to learn about the dot NET platform.  It was very
enlightening, and it underlined something that I think we need to
pursue.  Dot NET is all about making things easier on the developer,
so the framework takes care of transport issues (i.e. all components
are XML serializable by default), a common runtime, etc.

Microsoft focuses on the tools and the developers, while IBM, SUN,
etc. focus on hardware.  This is a fundamental difference.  The point
is that it seems like Microsoft has been listening to alot of the
complaints--esp. as relates to the developers.  Things like DLL hell
going away for .NET enabled applications because they borrowed from
NeXT's (and OS/X) distribution format prove that they are making
steps in the right direction.  It's all motivated to be the alpha
and omega of platforms, but that is beside the point.

How this affects us, is that for future development, I would like us
to persue making things really simple for the developer *using*
Avalon.  That means that we provide the tools (command-line/ANT/
GUI/etc.) that helps developers write Avalon components.  We provide
the test cases to make sure everything works properly.  It's about
our users (who happen to be developers).  It's not about having the
prettiest glass cathedral.  It's not about being perfect.  It's about
being useful.  It's about providing the best tools so that component
management is really easy.  It's about making it truly a higher cost
to do things the old way.

There are several things we can learn from the "dark company" to
make Avalon rock.  There are also some things that we can do to show
SUN just how J2EE *should* have been done.  Deployment should not
be a question mark.  We all have very different facilities available
to us.  We should all use that to our advantage.  It will also require
some of our "closet committers" to come out in the open and get their
hands dirty.

We should strive towards seamless integration in the way we declare
and store meta-data.  We should provide rock solid features--but have
a flexible enough architecture where we can experiment with new features
while we are making the core rock solid.

We should also strive (contrary to Microsoft) to encourage container
development outside of Avalon--which means we provide the tools to
validate and verify containers and how they interact with Avalon

To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message