On Tue, 18 May 1999 18:33:09 -0400, Amos wrote:

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...

I've been thinking about this some more, and all the pieces are falling together in favor of free-threading. There are no real disadvantages, and is harder to get wrong. In contrast, if we stick with apartment-threading then things can go wrong in subtle and hard-to-diagnose ways if COM interface pointers are stored across transaction boundaries. An essential part of this will be getting the relevent servers (ZServer, pcgi...) to correctly initialise COM every time they create a thread.

...

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.

IObjectSafety is used by Internet Explorer to check whether an object is safe enough to be scripted by an untrusted page in a _browser_. The security concerns of scripting that same control in the _server_ are probably close enough for our purposes. Unfortunately controls are generally only marked in this way if the author expects them to be used in a browser. Today this excludes a number of useful objects, but that proportion seems to be falling.

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...

Wouldn't all of that be easier in an ExternalMethod? All the COM-related bits are then implemented in straight Python, and theres even a book to help you with that ;-) I've been taking my COM with Zope like this since... well, since I first started using zope, and it works well enough for my purposes. Would it help to post some examples? One problem I see with the COMObject-as-database-connection approach is that most objects that would be useful in this arrangement will require some configuration. In contrast, my uses so far (and incidentally what ASP does well, if I understand correctly) have all involved stateless objects. It escalates the problem considerably to handle objects that have state, and are cached: At the moment COMObject stores the name of a class, and always creates a new copy of the class. The ideal approach (imo) would be for COMObject to store a persistant _instance_ of a COM object. The management interface would be extended to allow its properties to be manipulated interactively.... The whole effect would be very similar to how Visual Basic works as a control container. All very cool - I would love for someone to write this for me ;-) Toby Dickenson