Paul Everitt wrote:
"Can we make import-from-the-network have as acceptible a level of trust as the filesystem?"
Here are some brainstorm ideas:
1) Make the import a pull rather than a push. Instead of pushing the data from your computer into a remote Zope, you go to the remote Zope and put in the URL to your local Zope.
This would work well, I believe, except when the 'pulled from' system is behind a firewall. Perhaps some sort of 'trusted third party' arangement would work for these situations.
2) Turn import from the web off by default but have a knob to turn it on.
Add another knob as to whether the system allows itself to be pulled from(and who by). Ensure this doesn't become an avenue for denial-of-service attacks on the pulled from system.
3) Reading directly from a Zope as it outputs an export means you're less likely to get a hacked pickle.
4) Have a shared key system, then rotor the export file (this is what we do on the unreleased Zope Network Client software). That is, wrap the data in an envelope.
Of course there is still the ultimate question: is this a compelling feature?
Absolutely. Anything that you can do to increase Zope's 'Network Effect' is a Good Thing(tm). While increasing the functionality of individual Zope installations is obviously nothing to sneer at, any feature (like this one) that adds value to the network as a function of the network size is going to be a killer app. <OT> As a minor example, how about a product that creates the sort of file that slashdot.py consumes? For that matter, how about a version of slashdot.py that is more generalized? Both of these examples are much more limited than 'Remote Import' or the 'Network Client', yet still have a significant ability to promote and popularize Zope. I realize that I am talking through my hat here, as I am not capable of creating either of these products on my own. </OT> Michael Bernstein.