Tommi, I can agree with this, that a region exists is reflected by the state being online or offine, that it is reserved or not is none of the regions business...
Tommi Laukkanen wrote: > I would maybe add just offline/online states for region and make a > separate reservation table as fields required for reservation are > different from that of region. > > regards, > Tommi > > On Tue, Feb 3, 2009 at 7:00 AM, Dahlia Trimble > <dahliatrim...@gmail.com <mailto:dahliatrim...@gmail.com>> wrote: > > Then again one could assume if a record existed for that region > even if it were offline, that it's spot is reserved. > > > On Mon, Feb 2, 2009 at 8:50 PM, Frank Nichols > <fr...@thenichols.net <mailto:fr...@thenichols.net>> wrote: > > To me the region does not need to know if or when the reserved > status > would expire. Some process/module must have set it to > reserved, and to > me would then assume the responsibility of knowing when/if to > expire the > reservation. > > Dahlia Trimble wrote: > > I would think if a "RESERVED" state were added there would > probably > > need to be an expiration date associated with it. > > > > On Sat, Jan 31, 2009 at 8:23 PM, Frank Nichols > <fr...@thenichols.net <mailto:fr...@thenichols.net> > > <mailto:fr...@thenichols.net <mailto:fr...@thenichols.net>>> > wrote: > > > > There is a member in RegionProfileData (regionOnline) > which is > > currently > > not used and does not exist in the region db table. I > would like > > to add > > it to the region table as an enum and not a boolean. > Currently the > > code > > assumes a region that has an entry in the region table > is online > > (as far > > as I have figured out...) With this field in place we can > > impliment the > > requested feature of reserving regions as well as having > regions > > online > > but not available for logins. I suggest the following enums: > > > > RESERVED > > OFFLINE > > ONLINE > > > > at least for starters. > > > > Before submitting a patch to support this, i wanted to > get some > > direction and comments from the core developers and > architects. > > > > Frank > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev@lists.berlios.de > <mailto:Opensim-dev@lists.berlios.de> > <mailto:Opensim-dev@lists.berlios.de > <mailto:Opensim-dev@lists.berlios.de>> > > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev@lists.berlios.de > <mailto:Opensim-dev@lists.berlios.de> > > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de <mailto:Opensim-dev@lists.berlios.de> > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de <mailto: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