This concept was kicked off by a specific need that led to discussions of polling, XML-RPC, Java RMI, JavaScript, and others that I can't recall. But, an unrelated need brought it home last night. The ZSchool project will at some point involve lot's of folks who won't be online constantly*, and suddenly Client Side Zope starts to look interesting. Keep in mind, it's Zope! For those of you who have sworn off all things Microsoft and have grown accustomed to the "joys" of compiling and tweaking Zope / Apache / etc. on all varieties of *n*x, you may not realize that getting Zope running on Windows takes about five minutes. Thats five minutes for a newbie. It's just a Windows "Install". Now, if anyone mentioned Client Side Oracle Application Server, or Client Side Lotus Notes, we'd know they'd lost it. But Zope is actually small and nonintrusive enough to pull this off. Think about a world full of Zopelets, on all those nifty palm thingies. Your local WorldPilot could sync up with a central WorldPilot periodically, but you'd still have "all" your data available while you're off-line*. Same with Xen Project Manager, zSchedule, etc. Of course that's just the beginning. A generation of new apps we've not dreamed of yet that could make this thing explode, when we figure out how to really exploit XML-RPC, and whatever comes next! Later, Jerry S. * I'm not holding my breath for us all to have wireless persistent IP anytime soon . . .
Hmmm.... Very interesting, I agree that installing Zope on Win* was very easy. The problem I have is how to Sync stuff between my local Zope at home (no net connection) and the 'real' Zope at work. I currently do an export to a ZIP disk, and then an import back into the other Zope from the disk. This makes a lot of things possible but only in very limited circumstances: You have to move *all* of Zope, or objects don't re-import back into the correct place. Also, if an object changes on the 'real' Zope changes while I'm at home and I import when I get back, the changes are lost as my import overwrites whatever is there...not pretty. Also, I can't do this trick with things like Squishdot postings, which is a shame... What would be nice is something like Lotus Notes replication when you import a .zexp file; you get a replication conflict if both objects have changed, which you can then sort out. I'm not looking for the full-blown ZEO distributed object store, just a way to periodically sync a set of selected objects (slightly more complex in the squishdot case...) by exporting from one and re-importing (non-destructively) into another. Any ideas? Chris Jerry Spicklemire wrote:
This concept was kicked off by a specific need that led to discussions of polling, XML-RPC, Java RMI, JavaScript, and others that I can't recall. But, an unrelated need brought it home last night. The ZSchool project will at some point involve lot's of folks who won't be online constantly*, and suddenly Client Side Zope starts to look interesting.
Keep in mind, it's Zope! For those of you who have sworn off all things Microsoft and have grown accustomed to the "joys" of compiling and tweaking Zope / Apache / etc. on all varieties of *n*x, you may not realize that getting Zope running on Windows takes about five minutes. Thats five minutes for a newbie. It's just a Windows "Install".
Now, if anyone mentioned Client Side Oracle Application Server, or Client Side Lotus Notes, we'd know they'd lost it. But Zope is actually small and nonintrusive enough to pull this off. Think about a world full of Zopelets, on all those nifty palm thingies. Your local WorldPilot could sync up with a central WorldPilot periodically, but you'd still have "all" your data available while you're off-line*. Same with Xen Project Manager, zSchedule, etc. Of course that's just the beginning. A generation of new apps we've not dreamed of yet that could make this thing explode, when we figure out how to really exploit XML-RPC, and whatever comes next!
Later, Jerry S.
* I'm not holding my breath for us all to have wireless persistent IP anytime soon . . .
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Chris Withers wrote:
Hmmm....
Very interesting, I agree that installing Zope on Win* was very easy. The problem I have is how to Sync stuff between my local Zope at home (no net connection) and the 'real' Zope at work.
I currently do an export to a ZIP disk, and then an import back into the other Zope from the disk. This makes a lot of things possible but only in very limited circumstances:
You have to move *all* of Zope, or objects don't re-import back into the correct place. Also, if an object changes on the 'real' Zope changes while I'm at home and I import when I get back, the changes are lost as my import overwrites whatever is there...not pretty.
I'm a little pzzled about : "objects don't re-import back into the correct place" I haven't had any trouble exporting / Importing enitre branches. Of course, I delete the branch to be overwritten first, or at least move, or rename it. Is that how you're doing this?
Also, I can't do this trick with things like Squishdot postings, which is a shame...
What would be nice is something like Lotus Notes replication when you
import a
.zexp file; you get a replication conflict if both objects have changed, which you can then sort out.
XML export may come into play here, since the XML version is parsable. I'm not aware of any existing Zope tool for dunning a comparison process.
I'm not looking for the full-blown ZEO distributed object store, just a
way to
periodically sync a set of selected objects (slightly more complex in the squishdot case...) by exporting from one and re-importing (non-destructively) into another.
One point that I think is still evolving is a clear set of guidelines regarding what data is held in Zope, and what should be in other formats, such as Gadfly. As long as we diligently keep DTML doing templating, and avoid mixing tabular data and static content in with ZODB objects, it should be fairly straightforward to do Zope Exports of the Zope Framework, and file copies, or native exports of data in other "backends".
Any ideas?
Chris
Jerry Spicklemire wrote:
This concept was kicked off by a specific need that led to discussions of polling, XML-RPC, Java RMI, JavaScript, and others that I can't recall. But, an unrelated need brought it home last night. The ZSchool project will at some point involve lot's of folks who won't be online constantly*, and suddenly Client Side Zope starts to look interesting.
Keep in mind, it's Zope! For those of you who have sworn off all things Microsoft and have grown accustomed to the "joys" of compiling and tweaking Zope / Apache / etc. on all varieties of *n*x, you may not realize that getting Zope running on Windows takes about five minutes. Thats five minutes for a newbie. It's just a Windows "Install".
Now, if anyone mentioned Client Side Oracle Application Server, or Client Side Lotus Notes, we'd know they'd lost it. But Zope is actually small and nonintrusive enough to pull this off. Think about a world full of Zopelets, on all those nifty palm thingies. Your local WorldPilot could sync up with a central WorldPilot periodically, but you'd still have "all" your data available while you're off-line*. Same with Xen Project Manager, zSchedule, etc. Of course that's just the beginning. A generation of new apps we've not dreamed of yet that could make this thing explode, when we figure out how to really exploit XML-RPC, and whatever comes next!
Later, Jerry S.
* I'm not holding my breath for us all to have wireless persistent IP anytime soon . . .
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
[Jerry Spicklemire, on Thu, 09 Mar 2000] :: One point that I think is still evolving is a clear set of guidelines :: regarding what data is held in Zope, and what should be in other formats, :: such as Gadfly. As long as we diligently keep DTML doing templating, and :: avoid mixing tabular data and static content in with ZODB objects, it :: should be fairly straightforward to do Zope Exports of the Zope Framework, :: and file copies, or native exports of data in other "backends". Evolving set of guidelines? Can someone in the know take a crack at setting these down in writing?
At 10:50 AM 3/9/00 -0800, you wrote:
[Jerry Spicklemire, on Thu, 09 Mar 2000]
:: One point that I think is still evolving is a clear set of guidelines :: regarding what data is held in Zope, and what should be in other formats, :: such as Gadfly. As long as we diligently keep DTML doing templating, and :: avoid mixing tabular data and static content in with ZODB objects, it :: should be fairly straightforward to do Zope Exports of the Zope Framework, :: and file copies, or native exports of data in other "backends".
Evolving set of guidelines?
Can someone in the know take a crack at setting these down in writing?
Yeah, that would be very helpful. As a Zope Newbie, who's developed lots of database stuff in PHP and Perl, I am unclear on whether I'm "supposed to" try to make everything an object in ZODB. Say I'm making a repository of documents, like articles or e-mail messages, and I expect to end up with 100s of thousands of those, should I confidently work on making them all Zope objects, or should I stick with mySQL records and/or files in the file system, like I normally would? - Flemming o / \------------------ Flemming A. Funch ------------------------- / * \ New Civilization Network / Synchronicity Networks / * * \ ffunch@worldtrans.org o-------o----------- http://www.worldtrans.org/ --------------------
Flemming Funch wrote:
Say I'm making a repository of documents, like articles or e-mail messages, and I expect to end up with 100s of thousands of those, should I confidently work on making them all Zope objects, or should I stick with mySQL records and/or files in the file system, like I normally would?
I'll take a stab at this: Quantity of data doesn't tip the scales towards Zope or SQL. If you have small units of data that change frequently, SQL, using a non-transactional storage like BerkleyStorage, or packing frequently are all reasonable approaches. If you have a number of large (multimegabyte) files, the filesystem is probably the best place for them, with something like LocalFS. Also nice because you can have a "real" ftp server serving the files, but still use zope to reference them. If your data expresses several many->many relations, a relational database may be the solution, but don't underestimate the power of Zcatalog. for data expressing one->many relationships, ZODB rocks. In your example, I would use the ZODB because emails are always hierarchical, and use Zcatalog to let people slice & dice it. The articles would depend on what views you need to put on them and what metadata you want. You can also do some super neat stuff with ZODB+SQL, as the very illuminating Zope Question : Virtual folders / URL's thread is illustrating. -- mindlace@imeme.net good design is as close as I want to get to ideology.
participants (5)
-
Chris Withers -
Flemming Funch -
Jerry Spicklemire -
mindlace -
Patrick Phalen