commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [id] Review before 1.0 (Summary)
Date Sat, 14 Jan 2006 23:45:59 GMT
<snip/>
>
> For me the question is, does a normal user really care about the specifics
> of an unique id. The most difference is the returned type of the id,
> because that may impact other parts of the code (e.g. DB).

I think many apps will care about more than just the type as in string
or numeric, though I agree that the need for multiple different types
in one application will be rare.  Some applications will want the id
to be random, even "secure" (e.g. session ids), some will want
sequential ids, etc.  So I think the different types are significant.
The real questions are  a) do we care to make different
implementations within type pluggable and b) do we want to provide
static methods that get ids of the different types directly as a
convenience.  Answer to a) is probably leave it to the user and b) is
it is nice to have, but again gets unweildy with too many generators. 
So, I guess I am in favor of simplifying down to just providing the
implementations - no factory, no utils class.

<snip/>

>
> > One thing that I would like for us to consider is to omit the uuid
> > generators from 1.0.  There is a lot to do to get that package into
> > releaseable state, including spec compliance review, and I am a little
> > concerned with our ability to support it once released, as the
> > original developer is no longer working on this code.
>
> Uuuh! Cough! Bummer! When I look into the answers given to a lot of users
> over the last two years, they were always told, c-id is stable and
> reliable, we need just to close the minor issues left in Bugzilla and
> clean-up the docs.

I don't ever recall anyone using the terms "stable" or "reliable" in
reference to the UUID code.  The code from [lang] is certainly stable.
 I did respond to one inquiry with the statement that "The main thing
standing in the
way of promotion to commons proper and a release is review and validation of
the UUID code. "  The "review and validation" (against the spec) of
the UUID code is a lot of work, as you can see.

> I know quite some projects that use a snapshot of c-id
> to generate UUIDs in production (including some of mine).

I don't know what we can do to make it more clear that people should
*not* depend on code in the commons sandbox, or any unreleased
snapshots.

> And look into
> Bugzilla. We had not much issues about UUID and the last open one can be
> easily solved by different implementations for the state. My issue list
> targetted this area anyway (concerning Exception handling and the state
> problem in this area).

Again, the issue is validating the code and verifying spec compliance.

>
> > I would be +1
> > to cleaning up the rest of the package, promoting to proper and
> > releasing a simple 1.0 without the uuid generators.  I think the
> > package is quite useful without the uuid functions and if there is
> > sufficient community interest and support we can add the uuid stuff
> > into a 1.1.
>
> Fact is, that UUIDs are part of c-id now for exactly two years and despite
> the fact, that c-id had no proper release, they are already used. Even I
> cannot use c-id-1.0, if it is without UUID support ... :-/

This is a do-ocracy, so if you are willing to do the work to get all
of the UUID code into releasable state and verify compliance against
the spec, I am +1 to push forward.  I just thought that we could get
promotion and a release out faster if we omitted this package from the
1.0 plan.

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