RE: [Zope] Re: [Zope-dev] Re: [Zope] Import from Zope-1 to Zope-2
-----Original Message----- From: Michael Bernstein [mailto:mbernstein@profitscape.net] Sent: Thursday, September 09, 1999 12:42 PM To: Michel Pelletier Cc: zope-dev@zope.org; zope@zope.org Subject: [Zope] Re: [Zope-dev] Re: [Zope] Import from Zope-1 to Zope-2
Michel Pelletier wrote:
<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'.
Woah! Further experimentation shows that it is not this simple, but close. There would have to be some pretty nifty abstraction code above Client to do what you want, Client isn't much more powerful than XML-RPC, if at all, it's just more Zopeish.
In fact, unless I misunderstand, this will allow Zope applications to not only expose services to other servers, but will allow truly distributed applications...
Yep. Note that the performance won't be all that (because it's HTTP). This also doesn't really solve the problem of transparent database replication.
Will there be a separate set of permissions to allow/deny objects to be called like this?
No. 'Client' waddles, swims, and quacks just like a 'web browser' to Zope. If a method or object is protected by a certain permission, then the 'Client' call must supply a username and password that matches a user with a valid Role that can satisfy that permission. Just like a browser. If the server supplies a cookie, 'Client' will return it with the rest of the HTTP headers and you can store it seperatly (since 'Client' calls are stateless).
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?
As long as there is a 'stop' you can do this like any other recursive operation. By no-no I didn't mean you shouldn't do it, I meant you should be aware that it is recursive. -Michel
Michel Pelletier wrote:
-----Original Message----- From: Michael Bernstein [mailto:mbernstein@profitscape.net] Sent: Thursday, September 09, 1999 12:42 PM To: Michel Pelletier Cc: zope-dev@zope.org; zope@zope.org Subject: [Zope] Re: [Zope-dev] Re: [Zope] Import from Zope-1 to Zope-2
Michel Pelletier wrote:
<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'.
Woah! Further experimentation shows that it is not this simple, but close. There would have to be some pretty nifty abstraction code above Client to do what you want, Client isn't much more powerful than XML-RPC, if at all, it's just more Zopeish.
That's what I meant, a lower barrier to entry...
In fact, unless I misunderstand, this will allow Zope applications to not only expose services to other servers, but will allow truly distributed applications...
Yep. Note that the performance won't be all that (because it's HTTP). This also doesn't really solve the problem of transparent database replication.
I was actually thinking of a 'federated' database, with each server responsible for a portion of the content. Like a distributed version of dmoz.org, for example. Site maintainers could then pick and choose which other sites they want to cooperate with.
Will there be a separate set of permissions to allow/deny objects to be called like this?
No. 'Client' waddles, swims, and quacks just like a 'web browser' to Zope. If a method or object is protected by a certain permission, then the 'Client' call must supply a username and password that matches a user with a valid Role that can satisfy that permission. Just like a browser. If the server supplies a cookie, 'Client' will return it with the rest of the HTTP headers and you can store it seperatly (since 'Client' calls are stateless).
Umm, are you saying that if I make an object viewable by annonymous users, I can't avoid letting another Zope site from making a client call to examine the unrendered DTML? Or incorporate my content or functionality into their site? Frankly, I'd at least want to restrict it by the requesting IP address. Michael Bernstein.
participants (2)
-
Michael Bernstein -
Michel Pelletier