On Wed, 2005-03-30 at 15:31 -0600, Michael Giagnocavo wrote: > Well, we could just dump the GUID into the uniqueid field, but it is 32 in > length, and I'd have to increase it to 33 (minimum) or 37 (preferred, to > keep nice format). I figured increasing a field like that would probably > cause a ton of problems throughout the code that relies on it being 32 (say, > database fields). Maybe someone who knows more can chime in here...
As I understand the current UniqueID algorithm it uses a Hi-Lo approach with the high part being the startup time (or something similar - I dont recall exactly) and the low part being incremented by 1 each time a new id is generated. This approach has the advantage that it is really fast. If performance is a requirement for the UniqueId generation we could use the GUID for the high part and continue to use the incremented uniqueint for the low part. The increased field length might in fact be an issue i did not think of but is also present in the CDR only approach (at least when considering storing CDRs in a database). I don't think asterisk itself has a problem with this as the bristuff patches from Junghans already use an extended UniqueId inclunding the process id and a configurable node id. =Stefan
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Asterisk-Dev mailing list [email protected] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
