Hey folks, I've written a lookup module to store and manage generic name/value pairs, organized by "realms". For example: REALM NAME VALUE state MN Minnesota state TX Texas country US United States The basic premise is to keep this type of data in one place, rather than all over the map (e.g. a states table for ecommerce, a states table for something else, so-on.) With the lookup API, any module can stash/get its codes in the table, and it supports importing from a text file. I got used to working this way at my last job (a big Oracle shop - I think this model is called "one true lookup table") I'm considering using this for module settings to save memory. Some of my modules (e.g. send) have lots of settings for email templates, default message text, etc. It's silly to shove all of this into the variables table and haul it around on each page request, when 1 out of 5,000 page views will actually require it. So, I'd add: REALM NAME VALUE send template <html><body>... send message Here's some content from ... I still have a consistent place to stash these settings ( lookup_set () , lookup_get() ), but I only pull them as needed. An overall memory savings, and handy as well. The lookup_get() is functionally similar to the variable_get() function, except that it requires a $realm parameter: lookup_get($realm, $name=null); // without a name, it returns a keyed array of the whole realm My Questions: 1) There's potential overlap with variables and probably other stuff too. Is there a better way? 2) Is it weird to create a confusing-sounding component module like this and require it for other modules? Should this (or a derivative of this) functionality be available in core instead? Allie Micka pajunas interactive, inc. http://www.pajunas.com scalable web hosting and open source strategies