I have a question for the masters. If you are an impatient master, jump over the context and to the second to last sentence for the question. A friend and I are well into building up a Drupal 4.7 based site where the user's location is taken into account in nearly every display. The site, www.folkjam.org (or folkjam.org for some), is most simply a database of acoustic music jam sessions (Irish sessions, bluegrass, folk, fiddle, stuff like that). When a user visits the site, we determine their lat/lon from an IP to lat/lon database (a custom module we've added), or from user selection based on US zip code or finally from the zip code that the location module injects into the user's login record when a user registers and configures it. By the time we are done, every display in the site will show only nodes that a) have no locative data on them or b) Have locative data that is within a 90 mile radius of the user's configured location. We've come pretty far, but there is one key place where we need some direction. We intend to contribute much of our work back to Drupal (which is why I'm asking for help - I want the changes to be palatable). There are seven pieces of information that we need to store in a way that other modules can leverage them. Three are critical to a location-aware Drupal site. Four are important for display. They are: The site visitor's Latitude, Longitude, Radius (stored in miles), Country code, Postal code, Province, City. The Lat/Lon/Radius are the critical three. We are presently keeping these in session variables wrapped in accessor functions. The accessor functions are namespaced as part of the site specific glue module that brings most of our customizations together, and the session variables are too. Neither are appropriate for direct calls from contributed modules such as the event.module. In making event.module capable of only showing event-enabled nodes that are within $search_radius of a lat/lon, we started by adding GET style parameters and passing lat/lon/radius into the event.module. Because these three pieces of information needed to go all the way down the event module's call stack to the data retrieval routine, most functions had their signatures extended. Completing this work will require touching the entire event module theme as well, since the 'next month', etc navigation links all need the lat= lon= radius= parameters on the URL. We are not happy with this solution as something to contribute back. What we would rather do is store the seven location awareness information tidbits in a 'well recognized location' where other modules can know to use them. Then we want to add a setting to event.module that can be enabled to restrict events to within a search radius of the visitor's 'current location', and then modify the core data logic and display building logic in event.module to constrain the events it retrieves based on the lat/lon/radius in the 'well recognized location' when the location module is installed AND for nodes that have locative data AND when the active user has a lat/lon/radius configured. In reading the notes from the DrupalCon on Vancouver it seems that location awareness was a topic - I hope there is already some thought about this that I just didn't read. While I suspect that the $user object is probably the place to keep this, I am uncertain of how much we can rely on the $user object when the user is not logged in - we want to be able to customize displays even when users don't register with us or log in. Before fixing that little pocket of ignorance and becoming expert on the nuances of $user, I thought I'd seek advice. Hopefully that is enough context for you. Here's the question: What is an appropriate "well recognized location" within Drupal to keep these seven pieces of information? (latitide, longitude, search radius (storage in miles), country code, province, postal code and city. I'm looking forward to having an answer (or seven :) ) so that we can get closer to having patches in the patch queue. Scott