commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <joerg.schai...@gmx.de>
Subject Re: [id] Review before 1.0 (Summary)
Date Sun, 15 Jan 2006 20:56:29 GMT
Hi Phil,

Phil Steitz wrote:

> <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.

OK. Fine with me. I'll drop it.

>> > 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.

OK. You're right. Could not find anything else in the archives.

>> 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.

Release more often ? ;-)

>> 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.

Fair enough. Well, in this case I would really wait until uuid is ready.
Releasing c-id without uuid is IMHO worse than waiting longer for the
proper release. I am willing to work on it, but I cannot say a lot about
the compliance and if I really can handle that regarding my work load.
Nevertheless my simple code review produced enough tasks that have to be
done also for a final release. I'll just continue ...

- Jörg


---------------------------------------------------------------------
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