I am about ready to commit a more or less "rfbar" (refactored beyond all
recognition) version of the [lang] Identifier stuff into [uid]. Before I
commit anything, I want to get some feedback on the design and naming
choices. Here is what I have in mind (and code, more or less ;)
1. Keep the [lang] IdentifierFactory interface, but rename it
"IdentifierSequence." This is partly because I don't want to deal with
names ending in "FactoryFactory" (see below), partly because I see these
things as sequence generators, not class factories.
2. Change the Long and String subinterfaces to abstract classes named
"AbstractLongIdentifierSequence", "AbstractStringIdentifierSequence."
This is so they can include some default behavior. I also
added methods (with default implementations) to return the maximum and
minimum lengths (resp. values) of generated identifiers, as this is a
common request from users (wanting to know how long the ids can be).
3. Define an abstract IdentifierSequenceFactory class to enable pluggable
IdentifierSequence implementations of various kinds (including all of
those in [lang] and uuids as well). This class has a static newInstance()
method that uses [discovery] to locate a concrete factory, defaulting to
DefaultIdentifierSequenceFactory, which creates instances of the
IdentifierSequences provided with [uid]. The setup here is more or less
copied from the distribution framework in [math] (thanks, Brent!).
4. Create packages called "sequential," "random," and "uuid" to house the
IdentifierSequence implementations and farm out the inner class
implementations from [lang]'s IdentifierUtils into these packages. I see
all but the "StringSessionIdentifier" from [lang] as "sequential", the
former being "random." I also envision a "secure" package down the road
to house "secure random" and signed/verifiable identifiers.
5. Hack away all but the static methods and "handy singleton storage"
from [lang]'s IdentifierUtils and keep this as a convenience class.
6. Create a test framework for uid implementations.
One question that I have regards supporting pluggable strategies within
the (as yet unwritten) uuid implementation. I want to make sure that the
structure above will support this in a natural way. One approach would be
to add parameters that code strategy choices to
IdentifierSequenceFactory's uuidSequence method (similar to the way e.g.
"wrap" works in IdentifierUtils' factory methods). Another way would be
to have DefaultIdentifierSequenceFactory delegate to a proper uuid
sequence factory. I guess the framework will support either approach, so
this decision does not have to be made immediately; but I would appreciate
any thoughts/concerns that others have on this.
Comments? Suggestions? Volunteers?
I have all but 5. and 6. implemented now. I will likely finish these
today. I will commit something (so we have something concrete to talk
about) tomorrow or Mon. incorporating whatever feedback I get between now
and then.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
|