commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <p...@steitz.com>
Subject [uid]llang] Adding refactored [lang] identifiers to [uid]
Date Sat, 27 Dec 2003 17:06:46 GMT
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


Mime
View raw message