I think this is a valuable discussion to have. My view is that all object identifiers ought to be UUIDs as UUID type is developed specifically for that with bullet broof unique id generation algorithm where as all other id generation algorithms are either database specific or fail if you have distributed service or both. If we want to prepare for distributing all our systems then aiming for purely UUID based identification is a good step forward. In understand that in practice it might be a very long time before we can reach a point where all identifiers are of UUID type but if we consider this to be a design principle then the resolution is immediately valid for any new implementations we do.
On Sat, Feb 14, 2009 at 1:23 PM, Melanie <mela...@t-data.com> wrote: > Estate ID is a purely local concept that is likely to vanish in > newer viewers and the Hypergrid. There is no point in creating a > double-lookup scenario. > There is nothing that says that all objects must be GUID and no > point in refactoring for refactoring's sake. > > Melanie > > > Tommi Laukkanen wrote: > > Hello > > > > LL viewer quirks we must conform to but as with many other objects the > > primary key could be uuid and uint based id is kept around for ll viewer > > compatibility? Maybe it gets too messy in the end to be worth the > trouble. > > One can consider it once we get to have custom viewers which are not > leashed > > by SL protocol limitations. > > > > regards, > > Tommi > > > > On Sat, Feb 14, 2009 at 1:14 PM, Melanie <mela...@t-data.com> wrote: > > > >> Hi, > >> > >> the estate id _is_ a uint. It is not a UUID and was never meant to > >> be a UUID. The client sends and expects a UINT. > >> > >> Melanie > >> > >> > >> Tommi Laukkanen wrote: > >> > Hello > >> > > >> > I am working on Estate NHibernate storage and noticed that EstateID is > >> still > >> > of uint type where as most of other objects have been converted to > UUID > >> > identifiers. Is anyone interested in tackling this refactoring from > uint > >> to > >> > UUID. Its not a small job but it would make the database much cleaner. > >> > > >> > regards, > >> > Tommi > >> > > >> > > >> > > >> > > ------------------------------------------------------------------------ > >> > > >> > _______________________________________________ > >> > Opensim-dev mailing list > >> > Opensim-dev@lists.berlios.de > >> > https://lists.berlios.de/mailman/listinfo/opensim-dev > >> _______________________________________________ > >> Opensim-dev mailing list > >> Opensim-dev@lists.berlios.de > >> https://lists.berlios.de/mailman/listinfo/opensim-dev > >> > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev@lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev >
_______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
