[Zope] Import from Zope-1 to Zope-2

[Michel Pelletier]

"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