I vote for #1 - Paul
Nothing I am saying is particularly new here. However, before we
can jump into the nitty gritty details about what the API and
contracts should look like, we need to gain consensus on the
general direction. No matter what the course, I am willing to
help achieve the end goal. Let's get this out of the way before
we finalize Context contracts, start coding, etc.
Development Plan 1:
We continue to support our existing projects while we start fresh
on a new effort. The new effort will be a scalable container that
follows a "profile". Basically the container will only use the
features that are part of that profile and ignore everything else.
PROS: It is new code that we as a team must work together on. We
will have just as much functionality as we want without
worrying about functionality we don't want.
CONS: It requires a more complex validation layer (i.e. we need to
make sure that components that are used do not *require* the
functionality we left out of the profile).
Development Plan 2:
We adapt our current projects to the three/four tiered approach
(Tutorial, Micro, Standard, Enterprise). This is probably an easier
migration path, and it would leverage the existing code that we
already have.
PROS: It uses existing code to build upon. It is easier for a user
to determine what type of container that they need for the set
of components they are using.
CONS: It isn't new development, so there is potential for "my way is
better" conflicts. We may actually be more difficult to
determine consensus on the particulars of container/component
contracts.
Which way do we as a community want to support? Once we have the
general plan, let's put together the infrastructure and focus on it.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
