Greg Reddin wrote:
On 4/11/07, David H. DeWolf <[EMAIL PROTECTED]> wrote:
The one thing I would like to see done before a beta release (where I
think our users will start to expect the api to stabalize), is the
reorganization of some of the classes/packages. Specifically, there
have a few discussions on list regarding which module the filters,
listeners, and other entry points should live in and I would like them
to be consistent if nothing else.
It does seem that TilesDecorationFilter and TilesDispatchServlet are
misplaced. Personally I think all these things should be in tiles-core
instead of tiles-api. Personally, also, I like the organization of
tiles-api and would propose we just move those classes there.
I was thinking the opposite. . .that we should move all of the other
entry points into the API. If we have an api with no entry points, why
do we have an API? It's essentially useless.
Sorry if I seem argumenattive, but how many of these "one more thing"
changes are we going to do? It's been about 2 years since I first got
involved in the Standalone Tiles effort that was already ongoing and we
still don't have a release people can feel comfortable using.
On the contrary, I'm comfortable using it - in fact, have it in
production. I'm just not comfortable locking in to an API yet. I'm ok
with a beta (maybe even ga) for 2.0.3 if everyone else would be ok with
binary incompatibilities (class renames) for 2.1.x
We've pulled
the rug out from under our users multiple times and it seems people are
starting to choose other technologies because Tiles is viewed as
"unstable". It may very well be that the tide will turn the other way when
we do finally reach stability, but I fear our window of opportunity is
closing or has already.
Point well taken.
So, I'm not against the changes we're talking about. I think they are
good,
but add Antonio's compatibility layer and we could be looking at more
months
of alpha before things start to stabilize.
I'm not sure anyone proposed that the compatibility layer is required
for a beta or ga release.
If we're going to do this let's
identify a concise set of changes that are needed and commit to them so we
can give the users something to work with.
Sounds good to me. This is the last thing on my list. . .are there other
lists out there?
What say ye?
Greg
