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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
