I wanted to ask the list what people's thoughts were on the appropriateness of implementing a Slashdot-like site in Zope. I have looked at the Slashdot source code (in perl) and its pretty messy (to put it mildy). I hacked at it to get it to work with the free Sybase server on linux and it works reasonably well, but I haven't gone much beyond that. If a slashdot-like site were implemented on Zope, would an external SQL database be neccesary, or would the internal object database be enough? For searching? Building the Slashdot-style site on Zope has the attractive feature of being very customizable and modular from the get-go (something which Slashdot source code is trying to get to). Slashdot (the site) gets a LOT of traffic -- would a zope server be able to handle the (what I'm guessing is) hundreds of thousands of hits per day? Do we have to wait until the Medusa integration is complete (not that throwing together a slashdot clone can be done before digicool folks can get that done). One thing I'm wondering about is upgrading. Assuming that the slashdot clone is upgraded regularly, how does this affect product instances already in the object store (this is a general zope question). My understanding is that straight pickling is done -- only data is serialized, so if I change methods, I should be able to use new versions of products with objects created by older versions of a product.. But if I add or delete attributes, then I have to be careful... Finally, does the concept of a slashdot-like Product (or set of products) interest anyone? -Gabe
Gabe Wachob wrote:
I wanted to ask the list what people's thoughts were on the appropriateness of implementing a Slashdot-like site in Zope.
I think that would be a very good idea. I am currently working on implementing a news delivery site using a combination of Perl and Zope. I only have until Monday to complete a prototype so I guess it will be mostly based on the slashdot source which as you correctly noted is a bit messy :-) I plan to use Zope to implement features not in the slashdot code base to enable the users of the site to add features, which can be managed very well and very easily using the file upload / Netscape publishing capabilities of Zope.
I have looked at the Slashdot source code (in perl) and its pretty messy (to put it mildy). I hacked at it to get it to work with the free Sybase server on linux and it works reasonably well, but I haven't gone much beyond that.
If a slashdot-like site were implemented on Zope, would an external SQL database be neccesary, or would the internal object database be enough? For searching?
I am also curious to know this. I suspect an external database would be a better approach, simply because for the volume of articles / comments that could be in the site would make a Zope folder/document approach a bit unwieldy. I don't yet know enough about Zope to make any meaningful judgement call on this. What I am curious to know is how a more experienced Zope developer would go about this and how he would architect the site.
Building the Slashdot-style site on Zope has the attractive feature of being very customizable and modular from the get-go (something which Slashdot source code is trying to get to). Slashdot (the site) gets a LOT of traffic -- would a zope server be able to handle the (what I'm guessing is) hundreds of thousands of hits per day? Do we have to wait until the Medusa integration is complete (not that throwing together a slashdot clone can be done before digicool folks can get that done).
If you are looking for a quick hack, you may want to look at HTML::Mason which can do modular/component based stuff. I don't like that approach because code is mixed with data in their templates. If you want to do it right, then Zope + External DB + Apache might be nice. I haven't tried Medusa yet so caveat emtor.
One thing I'm wondering about is upgrading. Assuming that the slashdot clone is upgraded regularly, how does this affect product instances already in the object store (this is a general zope question). My understanding is that straight pickling is done -- only data is serialized, so if I change methods, I should be able to use new versions of products with objects created by older versions of a product.. But if I add or delete attributes, then I have to be careful...
Finally, does the concept of a slashdot-like Product (or set of products) interest anyone?
Oh very yes! And I can think of quite a few improvements !
-Gabe
On Sat, 16 Jan 1999, Guido Sohne wrote:
Finally, does the concept of a slashdot-like Product (or set of products) interest anyone?
I would be very interested in a minimal threaded discussion-thing... Maybe that could be some sort of core product or something? (I guess it might be possible to make a simple version with only documents and the tree-tag... Hm.) -- Magnus Lie Hetland www.pvv.org/arcadia <arcadia@pvv.org>
Guido Sohne wrote:
[...] a combination of Perl and Zope. [...]
Isn't mixing Perl- and Python-based solutions like mixing ammonia- and chlorine-based cleaners? They both work OK separately (though the first will smell much worse), but mix them together... And from someone named Guido, no less! For shame! (Then again, this week I wrote an interpreter implementing a substantial fraction of PostScript in Python, so my own sanity may be in question. :^)
Ty Sarna wrote:
Guido Sohne wrote:
[...] a combination of Perl and Zope. [...]
Isn't mixing Perl- and Python-based solutions like mixing ammonia- and chlorine-based cleaners?
(snip) We've had a number of requests to be able to access Perl from Zope. I assume that Perl has an embedding API. I'm guessting that it should be possible to "embed" (at least some part of) Perl in Python and make it available as a Zope extension facility. Alas, I haven't had time to investigate this. Has anyone ever tried embedding perl in Python? Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
On Sat, Jan 16, 1999 at 01:31:03AM -0800, Gabe Wachob wrote: ,----- | I wanted to ask the list what people's thoughts were on the | appropriateness of implementing a Slashdot-like site in Zope. This is the application that I have been looking at Zope for. I am thinking of something that is a cross between Slashdot and c|net. (Or you can think of it as Slashdot with a category hierarchy.) | I have looked at the Slashdot source code (in perl) and its pretty messy | (to put it mildy). I hacked at it to get it to work with the free Sybase | server on linux and it works reasonably well, but I haven't gone much | beyond that. I didn't even put in the effort to get the Slashdot code running after taking a look at it. | Finally, does the concept of a slashdot-like Product (or set of | products) interest anyone? Yes! I'd be interested in using/contributing to this. After seeing someone else's message, I took a look at HTML::Mason for perl, and that just does not have the same power that Zope does. | | -Gabe | | `----- Kevin -- Kevin Dangoor kid@ans.net / 734-214-7349
I wanted to ask the list what people's thoughts were on the appropriateness of implementing a Slashdot-like site in Zope.
It's something I've been pondering for a little bit, but without the time to figure out what would really be involved. The Linux Weekly News is currently done entirely with a straight hierarchy of HTML files. That makes management of the information harder than we would like it to be, to say the least. I've wanted to put together some sort of database-driven backend for a while. Zope is, at this point, at the top of the list of technologies to look at for this task. If you get a project going in this area, we would be interested in what you come up with, and, depending on other factors here, perhaps able to contribute as well. jon Jonathan Corbet, Eklektix, Inc. corbet@eklektix.com
participants (7)
-
corbet＠eklektix.com -
Gabe Wachob -
Guido Sohne -
Jim Fulton -
Kevin Dangoor -
Magnus Lie Hetland -
Ty Sarna