Hi All! One of the applications I am working on is a database client with a bunch of search screens and some fairly dynamic SQL. The search items themselves are selected from other query results necessitating a mechanism for data to be saved between HTTP sessions. I considered saving the data in a database and sending a cookie ID to the client which seems to be the norm, but for what I wanted it seemed like a bit of overkill. Maybe it's not, but anyway... Also, most of the documents use sets of data that are different for each user and need to be accessed with each request. So, I tried to save everything in cookies. This would eliminate the need for DB management on the server side and give the documents the data they need at the expense of slightly higher network traffic (not much of a problem on my company intranet). Well, I ran out of cookies. As you all probably know, the cookie spec calls for a browser to only handle 20 cookies per server. So, being the type that tends to just hit things harder when they don't work the way he wants them to, I wrote the CookieCutter Product. The CookieCutter Product manages a dictionary of objects. The objects are assigned to the dictionary keys, pickled, and added to REPONSE.cookies. It is unpickled from REQUEST.cookies and, if desired, the dictionary items are mapped into the REQUEST namespace where they can be then used as normal attributes. This allows the storage of a number of arbitrary objects in a single cookie. Cookies have a 4KB limit so I don't know how far this can go before either the browser or the user gags but, for what I'm using it for anyway, it works well. I'm still a bit new at all this so, for all I know, it could be a really braindead idea. Is anyone interested? Comments? John Jarvis Tokyo Electron FE, Ltd.