Toby Dickerson:
Thanks for posting the COMObject product Amos.... very interesting reading. I have some first impressions that I thought I would share:
1) I suspect there is a problem with the current implementation on multi-threaded servers. ...
Thanks for this warning. I'm definitely out of my league here. These are the sort of issues I was hoping others would be able to provide more guidance on. I don't really understand the relative trade off of not caching versus using free-threading...
2) Providing uncontrolled access to COM objects leaves a very big security hole in the server. This could be partly avoided if COMObject used the IObjectSafety com interface to restrict how the object can be used. I'm not sure how useful such a product would be... any thoughts?
I agree about the security problem. I'm not familiar with the IObjectSafety interface, however. I gotta get that Python/COM book ;-) My basic idea was the COMObject would be similar to a database connection object. You probably wouldn't manipulate it directly, and probably only Managers could access it. You would then create DTML Methods with proxy roles of Manager to do some specific thing to the COMObject. Then you'd call those DTML Methods in your normal old DTML. Maybe there should even be a COMMethod object to do this kind of work... Does any one know how ASP handles these sort of issues? I must confess, I've never used it. ;-) Thanks for your thoughts! -Amos