RE: [Zope] - Why I don't think Zope will work for me
Andreas wrote:
filesystem (if I'm allowed too). Even better I can upload an .tar.gz of the whole site at once, ...
You can do this with Zope and the database as well. Just write something that takes an HTTP upload file and unravels everything into Zope objects.
Not really. FTP is not acceptable as it unencrypted. ;) That
Do you think your position is the common view, or do you feel that most web site tools and ISPs use FTP as the publishing protocol? Instead of arguing about different approaches to solving the problem, I woner if anyone agrees what the problem is? Does the original poster want to be able to use his editor of choice? His site management tool of choice? Load a bunch of things at one time by working offline and doing batch update? I expect us to support all of those things. I would also like to see the community work on some sample packages. But our approach will be to stay within the object system. Treating the information as data that can be manipulated outside of the object system, outside the business rules and transaction manager, winds up busting a lot of the value that Zope tries to deliver.
Actually, I've come up with a tiny Zope replacement :)
If you're using Zope, then you're using Bobo. You've come up with a Zope package and we certainly encourage you to share it with everyone. Just because Zope includes an object database DOES NOT mean that everyone has to use it. Just because Zope includes integration with relational database DOES NOT meant that everyone has to use relational databases. Just because Zope includes integration with Apache DOES NOT mean that Zope only supports Apache ... I'd be thrilled to see someone contribute a package that lets administrators optionally merge in data stored on the filesystem. --Paul Paul Everitt Digital Creations paul@digicool.com 540.371.6909
On Wed, 30 Dec 1998, Paul Everitt wrote:
Andreas wrote:
filesystem (if I'm allowed too). Even better I can upload an .tar.gz of the whole site at once, ...
You can do this with Zope and the database as well. Just write something that takes an HTTP upload file and unravels everything into Zope objects. But when the primary repository is a file tree, why use BoboPOS in the production environment? Why should I need to reload the files, instead just typing C-x C-s in Emacs and Reload in Netscape (C-x C-s is save file in emacs ;) )?
Not really. FTP is not acceptable as it unencrypted. ;) That
Do you think your position is the common view, or do you feel that most web site tools and ISPs use FTP as the publishing protocol?
Nobody said that the common view is the right one. The common view is that Win98 is a very good OS (and not a graphical shell of CP/M emulating program loader), and only NT is even better. Actually commonly NT is regarded as the best OS. Right? Additionally, common view dictates that security doesn't matter. Perhaps this is right. (But then, a competitor of mine, when pressed hard, had to admit that security for his product is the users responsibility, and NO SANE user would connect the Windows PC that is used to surf the Internet to the company's LAN that transmits sensitive data. *hahaha*) But then common view is the wrong view when considering security. (I once fall for this: I considered it ``common view'' that it's ok not to protect a dialup workstation, as it doesn't have static IP, so it probably will not be hacked, etc. That was also the only box I'm responsible for that was hacked. I've been luckily sitting at the workstation and could turn off the modem in seconds. Since then even dialup boxes are protected via a probably consifured firewall ;) )
Instead of arguing about different approaches to solving the problem, I woner if anyone agrees what the problem is? Ok, than lets consider two scenarios: A: The Zopeserver is at your office, behind a firewall that lets only port 80 into the LAN. B: The Zopeserver is colocated with your ISP. And the ISP uses one physical segment for all the colocated servers and also the dialin modems.
Now let's consider two solutions: 1: http/ftp, unsecured, etc. 2: https, ssh-based stuff, etc. Now let's paint a nice box. | A | B | -------------------------- 1| OK | Game Over | -------------------------- 2| OK | OK | -------------------------- Notice one thing: The secure solution works in all cases secure. :)
Does the original poster want to be able to use his editor of choice? Actually, yes. His site management tool of choice? Load a bunch of things at one time Also yes. by working offline and doing batch update? That's too important.
We just got sidetracked into the security, etc. debate somewhere because someone considered the problem solved by mentioning Medusa/FTP ;)
I expect us to support all of those things. I would also like to see the community work on some sample packages. But our approach will be to stay within the object system. Treating the information as data that can be manipulated outside of the object system, outside the business rules and transaction manager, winds up busting a lot of the value that Zope tries to deliver. No question. But the question is, do most users need these tools. Is not a clean interface to existing working environements more important.
The important point for me is not even batch updates, emacs. etc. The point is, that I save in Emacs, switch screen, press reload, and I see if my HTML/CSS looks better or worse. Actually, I've been doing also webbased edits (when checking the stuff for IE with Win98, and it's just not the same: A <TEXTAREA> sucks.). Now you are proposing a checkout/checkin model. This basically also is not a solution: -) I get my beloved emacs. But: -) The quick turnaround (save/reload in netscape) is complicated by a convert and upload to Zope step.
Actually, I've come up with a tiny Zope replacement :)
If you're using Zope, then you're using Bobo. You've come up with a Zope package and we certainly encourage you to share it with everyone.
The problem is that it's not a Zope package :) It's a Bobo App :)
Just because Zope includes an object database DOES NOT mean that everyone has to use it. Just because Zope includes integration with relational database DOES NOT meant that everyone has to use relational databases. Just because Zope includes integration with Apache DOES NOT mean that Zope only supports Apache ... Right. But: -) Zope sounds a bit like a Mercedes 600SEL, when all what I need is, is a bicycle. (the 500kg analogy is a bit overused herearounds *g*) -) Even worse, at the moment it forces me to use a nonthreaded model. (Not good for sites containing streaming chats and/or long running SQL statements.)
Actually, to return to the security example B: I've never signed anything forbidding me to turn on promiscious mode on my colocated server (for whatever reason). So basically, with some time I could collect the passwords for all virtual server at that ISP that use FTP, I could collect all other plain text passwords, etc. Now, I do not have the time and inclination, but how many of ``my neighbours'' are in fact already root-hacked? The point is, that FTP is too unsecure, even if you are using a dialin modem of the ISP where your site is hosted. (At least with my ISP.) Now, let's consider the thread situation: -) E-Commercial servers: Probably contain credit card data. I'd assume that at least there is one capable hacker on the Internet interested in these. -) Non-commercial organizations: Could be quite a PR fuckup, if your site proclaims exactly the opposite of your official line. (Happened once the the Webserver of the ruling majority party in Austria *g*) -) Private topic sites: Let's consider you have a site for car lovers. Don't you think that one the whole world, there is not one script kiddie that dislikes cars? (Or you have a site that advocates public transportation. Now we need just one script kiddie that likes cars *g*) So basically, there is almost no service that is completly threat-free. Summary: When diving in a place with many, many enraged sharks, never let yourself be talked into diving without your iron suit. (And yes 99% of the Internet users are quite nice guys. But 1% of the Internet is quite huge pool of bad talents.) Andreas -- Win95: n., A huge annoying boot virus that causes random spontaneous system crashes, usually just before saving a massive project. Easily cured by UNIX. See also MS-DOS, IBM-DOS, DR-DOS, Win 3.x, Win98.
participants (2)
-
Andreas Kostyrka -
Paul Everitt