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
On 18 May 99, at 18:33, Amos Latteier 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'm still trying visualize how COM objects would fit best within Zope. I'm not sure that caching is the 'best way to go', unless the caching was on a per-client basis, or shared only if specifically configured that way. How do cached com objects time out? How exactly is caching supposed to work? As far as CoInitialize in each thread, I was wondering if that was part of the problem we had, but I see also the threading model is an issue. Although I can call ActiveX components from an interactive python, they die in Zope as pointed out previously.
I agree about the security problem. I'm not familiar with the IObjectSafety interface, however.
Is this a COM+ thing?
I gotta get that Python/COM book ;-)
Is there really a book? Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com ICQ: 14856937
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
participants (3)
-
Amos Latteier -
Brad Clements -
htrd90@zepler.org