And as I've just figured out by trying to convert some stuff to sessions, a not unconsequential result of allowing session variables to be acquired (if only for read purposes), is that existing code is easier to adapt. I might now call a script without burying form variables or parameters in the URL. If I use implicit acquisition (where the posted form data and URL data is read FIRST), then I can gracefully upgrade these scripts without changing anything. With the current scheme I have to go and search out all occurences of variables like "customer_id" and change them to session syntax. So I guess I'm arguing that the read case and write cases are fundamentally different, that you basically want to support the introduction of session variables into the namespace for read purposes through acquisition, and it's (marginally) OK if read/write don't share the same syntax. Bob Bob Sidebotham wrote:

The advantage of the last form (below), is that you can use acquisition, and don't need to know whether the variable came from the session or from elsewhere. If you *really* want it to come from the session only, you can always add the "only" tag to the dtml-with call.

__________________________________________________ Do You Yahoo!? Yahoo! Photos - Share your holiday photos online! http://photos.yahoo.com/