ZSyncer is a cool product but.... It isn't recursive and it's not scriptable. I need a product that synchronizes client from a parent site recursively through the folder structure, but configuable so that certain folders and their descendants are not synced. I also need the difference test to be something a bit more robust than date/time since some clients get hot patched and can possibly get out of sync. (The fix was done to the master but not distributed, but the secondary got hot patched with a hotfix...) Suggestions?
On Mon, Jul 28, 2003 at 01:09:45AM -0700, Dennis Allison wrote:
ZSyncer is a cool product but....
It isn't recursive and it's not scriptable.
Oh, I have a lot more complaints with it than that ;-) Check the CVS sources, read the TODO that I've been piling ideas into.
I need a product that synchronizes client from a parent site recursively through the folder structure, but configuable so that certain folders and their descendants are not synced.
Yes, recursion would be very useful in some situations and is on the TODO list. I hadn't thought about configuration such as you suggest. Can you elaborate on your requirements a bit? The first idea that occurs to me is to add a text entry to the sync view in which the user can enter an expression (TALES?) that needs to pass before recursing into a subobject.
I also need the difference test to be something a bit more robust than date/time since some clients get hot patched and can possibly get out of sync. (The fix was done to the master but not distributed, but the secondary got hot patched with a hotfix...)
yes, date/time comparison is very naive and not at all reliable. I've outlined many possible improvements in the TODO. I've had no feedback on them yet, comments and better ideas would be very welcome.
Suggestions?
Yes - help us improve zsyncer! :-) If you have time to work on any of this stuff, send patches to the maintainers listed at Sourceforge. I'd be very interested in testing any patches and I can check them in for you. If that gets too cumbersome, we should be able to get you writeable CVS access. -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's THE SINGLE MOTHER! (random hero from isometric.spaceninja.com)
We are running many independent instances of Zope front-ended by Pound. Some are Production machines P0, P1, P2, ... One is a development machine E. We also have a golden master machine S that contains the released version of the code that is shared by P0, P1, etc. Not all of the instance code is the same. Our development workflow is to create and test on E, then sync that code with the code on S. (Updates are not localized -- bug fixes and feature additions). On a regular schedule we update the production systems, but only a portions of the tree. And we're from that part of the world that wants everything scripted and repeatable without any hand work.... My posting was motivated by the prospect of having to examine and hand synchronize several hundred directories :-(. -d On Mon, 28 Jul 2003, Paul Winkler wrote:
On Mon, Jul 28, 2003 at 01:09:45AM -0700, Dennis Allison wrote:
ZSyncer is a cool product but....
It isn't recursive and it's not scriptable.
Oh, I have a lot more complaints with it than that ;-) Check the CVS sources, read the TODO that I've been piling ideas into.
I need a product that synchronizes client from a parent site recursively through the folder structure, but configuable so that certain folders and their descendants are not synced.
Yes, recursion would be very useful in some situations and is on the TODO list. I hadn't thought about configuration such as you suggest. Can you elaborate on your requirements a bit? The first idea that occurs to me is to add a text entry to the sync view in which the user can enter an expression (TALES?) that needs to pass before recursing into a subobject.
I also need the difference test to be something a bit more robust than date/time since some clients get hot patched and can possibly get out of sync. (The fix was done to the master but not distributed, but the secondary got hot patched with a hotfix...)
yes, date/time comparison is very naive and not at all reliable. I've outlined many possible improvements in the TODO. I've had no feedback on them yet, comments and better ideas would be very welcome.
Suggestions?
Yes - help us improve zsyncer! :-)
If you have time to work on any of this stuff, send patches to the maintainers listed at Sourceforge. I'd be very interested in testing any patches and I can check them in for you. If that gets too cumbersome, we should be able to get you writeable CVS access.
--
Paul Winkler http://www.slinkp.com Look! Up in the sky! It's THE SINGLE MOTHER! (random hero from isometric.spaceninja.com)
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
On Mon, Jul 28, 2003 at 09:56:03PM -0700, Dennis Allison wrote:
And we're from that part of the world that wants everything scripted and repeatable without any hand work.... My posting was motivated by the prospect of having to examine and hand synchronize several hundred directories :-(.
OK. Can you maybe write some pseudocode of what you'd like your script to be able to do? I don't know when I'm going to get to do more work on zsyncer, but it's on my list... and we use zsyncer daily at work, so it'll get to the top of my stack eventually :-) meanwhile, there are a couple other developers listed at sourceforge... haven't heard anything from any of them lately... anybody up for helping Dennis out? -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's INTER VENTRILOQUIST! (random hero from isometric.spaceninja.com)
Thanks Paul. I'll browse the CVS and write something up. I have to get something up for our site soon so I have some motivation to work on the product ;-) On Tue, 29 Jul 2003, Paul Winkler wrote:
On Mon, Jul 28, 2003 at 09:56:03PM -0700, Dennis Allison wrote:
And we're from that part of the world that wants everything scripted and repeatable without any hand work.... My posting was motivated by the prospect of having to examine and hand synchronize several hundred directories :-(.
OK. Can you maybe write some pseudocode of what you'd like your script to be able to do?
I don't know when I'm going to get to do more work on zsyncer, but it's on my list... and we use zsyncer daily at work, so it'll get to the top of my stack eventually :-) meanwhile, there are a couple other developers listed at sourceforge... haven't heard anything from any of them lately... anybody up for helping Dennis out?
--
Paul Winkler http://www.slinkp.com Look! Up in the sky! It's INTER VENTRILOQUIST! (random hero from isometric.spaceninja.com)
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Paul, I've made come progress on a 'son of zsyncer' product and have a pre-pre-alpha Product which I need to use as a tool ASAP. I have encountered some difficulties which I hope you can assist me in resolving. My new product re-uses some of ZSyncer, particularly the basic authentication code and some of the transport code. It seems to work fine between sites which us basic authentication only but gets confused when the sites use cookie authentication. ZSyncer authenticates and transfers over links that my "son of ZSyncer" product fails on. The transport mechanism reports a 500 status to the sender; the receiver reports a 401 error (I think) and does so as "Anonymous" rather than the user under whose guise the transfer is being performed. If you have the time and interest, I'd be happy to share the code even in it's currently hacked-up state.
On Thu, Aug 21, 2003 at 07:36:32AM -0700, Dennis Allison wrote:
Paul,
I've made come progress on a 'son of zsyncer' product and have a pre-pre-alpha Product which I need to use as a tool ASAP. I have encountered some difficulties which I hope you can assist me in resolving.
maybe...
My new product re-uses some of ZSyncer, particularly the basic authentication code and some of the transport code. It seems to work fine between sites which us basic authentication only but gets confused when the sites use cookie authentication. ZSyncer authenticates and transfers over links that my "son of ZSyncer" product fails on. The transport mechanism reports a 500 status to the sender; the receiver reports a 401 error (I think) and does so as "Anonymous" rather than the user under whose guise the transfer is being performed.
hmm, afaik zsyncer doesn't make any effort handle cookies, in fact the xmlrpc code specifically only uses basic auth. Did you write some cookie code?
If you have the time and interest, I'd be happy to share the code even in it's currently hacked-up state.
sure... no guarantee i'll be able to fix anything but i can look. Currently i've got a nasty problem with zsyncer itself... seems to be failing when syncing from a site that uses FileStorage to a site that uses DirectoryStorage, and i have no idea why but i need it to work ASAP so i'm rather busy :-( -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's DESTRUCTO-! (random hero from isometric.spaceninja.com)
Thanks Paul -- I am putting out another fire at the moment too. I have finally isolated my problem to the cookie authentication interaction although why ZSyncer works and my stuff doesn't remains a mystery. I have been working on cookie authentication code since there is no way I can back off to BasicAuthentication. I'll follow up on this when things get a bit less crazy. On Thu, 21 Aug 2003, Paul Winkler wrote:
On Thu, Aug 21, 2003 at 07:36:32AM -0700, Dennis Allison wrote:
Paul,
I've made come progress on a 'son of zsyncer' product and have a pre-pre-alpha Product which I need to use as a tool ASAP. I have encountered some difficulties which I hope you can assist me in resolving.
maybe...
My new product re-uses some of ZSyncer, particularly the basic authentication code and some of the transport code. It seems to work fine between sites which us basic authentication only but gets confused when the sites use cookie authentication. ZSyncer authenticates and transfers over links that my "son of ZSyncer" product fails on. The transport mechanism reports a 500 status to the sender; the receiver reports a 401 error (I think) and does so as "Anonymous" rather than the user under whose guise the transfer is being performed.
hmm, afaik zsyncer doesn't make any effort handle cookies, in fact the xmlrpc code specifically only uses basic auth. Did you write some cookie code?
If you have the time and interest, I'd be happy to share the code even in it's currently hacked-up state.
sure... no guarantee i'll be able to fix anything but i can look.
Currently i've got a nasty problem with zsyncer itself... seems to be failing when syncing from a site that uses FileStorage to a site that uses DirectoryStorage, and i have no idea why but i need it to work ASAP so i'm rather busy :-(
--
Paul Winkler http://www.slinkp.com Look! Up in the sky! It's DESTRUCTO-! (random hero from isometric.spaceninja.com)
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
participants (2)
-
Dennis Allison -
Paul Winkler