RE: [Zope] Import from Zope-1 to Zope-2
-----Original Message----- From: anders.brun@abc.se [mailto:anders.brun@abc.se] Sent: Tuesday, September 07, 1999 05:24 To: zope@zope.org Subject: [Zope] Import from Zope-1 to Zope-2
Hi,
I have a site built in Zope version 1.10.2 (binary release, python 1.5.1, linux2-x86). Now I´d like to export everything into Zope-2. It doesn´t work using export/import ... Have anyone experiensed anything similar?
The answer is to use the upgrade utility in the utilities dir but on a related note heres another idea I had. How about a product that can mount one zope ODB into another. Using XML-RPC or something to connect the two sites togeather over the internet. It may not be fast enough for using that way but at least it would be really easy for transfering data between zope odb's.
"Jay, Dylan" wrote:
-----Original Message----- From: anders.brun@abc.se [mailto:anders.brun@abc.se] Sent: Tuesday, September 07, 1999 05:24 To: zope@zope.org Subject: [Zope] Import from Zope-1 to Zope-2
Hi,
I have a site built in Zope version 1.10.2 (binary release, python 1.5.1, linux2-x86). Now I´d like to export everything into Zope-2. It doesn´t work using export/import ... Have anyone experiensed anything similar?
The answer is to use the upgrade utility in the utilities dir but on a related note heres another idea I had. How about a product that can mount one zope ODB into another. Using XML-RPC or something to connect the two sites togeather over the internet. It may not be fast enough for using that way but at least it would be really easy for transfering data between zope odb's.
We are entertaining the possibility of putting ZPublisher.Client into the _ DTML Namespace. I am primarily championing the idea. 'Client' offers many cool uses. 'Client.Function' will call a remote 'Zope Method' which marshals simple types around (int, list, tuple etc.) and act as Zope oriented RPC. 'Client.call' is a convienent wrapper around 'Client.Function'. These both have the upshot of working with any URL, turning non 'object content' into file Message objects and return them in a list. Even cooler, 'Client.Object' will create surrogate objects of remote Zope objects. If you have a DTML Document on machine A, then Machine B could say: <dtml-with "_.Client.Object('http://A/YourDocument')"> <dtml-var id> </dtml-with> and print 'YourDocument'. You can pass autentication information in to all of the calls to access restricted object. The downside is that this is the first method to be introduced into DTML namespace that may block forever (not so say that in the past other methods didn't block because of bugs ;). The reason why there are no blocking methods is because Zope used to be single threaded. If the above Client calls took a minute to return, then your entire system hung for a minute. Granted, the OS should eventually time out the socket. Now that Zope is multi threaded, this isn't much of an issue, but it should be understood that these calls block and will take time and maybe hang individual threads for a while. Another no-no would be for an object to call Client on itself. I suspect this would cause some sort of StackOverflow exception. I'm not sure how well Zope would take that kind of behavior. The proposal mearly needs to pass the scrutiny of our security dictator. It is a trivial change to the code. I think it's pretty safe since no holes are introduced in the server, just client functionality, and any security bugs this could reveal could be just as easily exploited in python with Client or urllib (immagine, hacking machines in DTML!! It *is* a real language ;). -Michel
Michel Pelletier wrote:
Even cooler, 'Client.Object' will create surrogate objects of remote Zope objects. If you have a DTML Document on machine A, then Machine B could say:
<dtml-with "_.Client.Object('http://A/YourDocument')"> <dtml-var id> </dtml-with>
and print 'YourDocument'. You can pass autentication information in to all of the calls to access restricted object.
Excelent! Content and sevice syndication among Zope sites without going through RSS or XML-RPC! This will start a snowballing of Zopes 'network effect' and increase the value of belonging to the Zope 'network'. In fact, unless I misunderstand, this will allow Zope applications to not only expose services to other servers, but will allow truly distributed applications... Will there be a separate set of permissions to allow/deny objects to be called like this?
Another no-no would be for an object to call Client on itself. I suspect this would cause some sort of StackOverflow exception. I'm not sure how well Zope would take that kind of behavior.
Hmm, what if you have Zope behind Apache running two or more virtual domain names? can they call each other using this method? Cheers, Michael Bernstein.
participants (3)
-
Jay, Dylan -
Michael Bernstein -
Michel Pelletier