>Another tip- if you want to make this object stateless, (which you should) you should not be doing this work in the init method, but in some "initialize" method that you can call at the beginning of every client-called function, because you can't be guaranteed that the init method will be called every time the object is "created" (you could actually get a cached object).

I have not seen this happen (yet?) but I was trying to explain this to someone else, does the below example make sense:

User1 loads up your COM object and uses it and then stops using it (leaves
the web page or releases it from VFP/VB/etc). The init method fires for
this user, your custom methods fire, and then the destroy method fires.
But the pool manager (FoxISAPI or MTS), instead of actually releasing the
object from memory, keeps it in its RAM pool.

User2 loads up your COM object and uses it and then stops using it. The
init method won't fire because the app object has already instantiated.
Your custom methods will work - but maybe not if there is path
information that gets setup in the INIT. The destroy method fires. The
object goes back in the poool.