On 10/31/10 6:51 PM, Kiran Ayyagari wrote:
hi Emmanuel,
On 10/31/10, Emmanuel Lecharny<[email protected]> wrote:
Hi guys,
now that the configuration branch has been merged back to trunk (with
some bump in the road, I must admit : I just fixed some badly merged
IMO np, what you have done was huge in the branch
file, which caused some errors), I'm now checking some classes that may
need a bit of refactoring : the Index hierarchy.
There is a base Index class, with two main children : AvlIndex and
JdbmIndex. There is a third child, named genericIndex, which is only
used to deal with junit annotations used to create a new server instance
(it's a holder class). I was wondering if it would not be better to use
the created IndexBean we have in server-config, but obviously, we can't
if the beans are in server-config.
I suggest that all those beans are moved to core-api, then used by the
core/server-annotations projects to store the server configuration.
That would help simplifying the Index hierarchy.
I initially agreed for move on IRC but on a second though after
reading this mail I think we
shouldn't do this:
1. Moving all the beans to core-api *might* make other developers to use them
everywhere in the code (be it in our server or in their apps) which IMHO
not
desirable for us.
Hmmm, that's right.
2. Having GenericIndex makes creating a index implementation easier and we
can
introduce a type parameter in the @CreateIndex annotation to
support various
index implementations. e.x @CreateIndex( type=AvlIndex.class, ..)
Well, I still think we should get rid of the GenericIndex, bt if we can
default to using JdbmIndex if we don't have any type parameter, then we
can remove the GenericIndex and not use the IndexBean either.
Seems fine. Will try to do that this way.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
