[ZWeb] Re: Zope.net
Mon, 13 Jan 2003 15:18:48 +0100
On Monday, Jan 13, 2003, at 14:53 Europe/Paris, george donnelly wrote:
> [Paul Everitt]
>> It seems that you, Kapil, George, and I are talking about some of the
>> same ideas. I took a few minutes this morning to write up a proposal:
> Retrieve the RSS listing from each site
> This could get expensive. I'm thinking of the example of weblogs.com
> checked all the weblog sites every hour i think to see if there were
> updated. What about a reverse approach, where community sites "ping"
> central site when they have something new they want added? This would
> out the "cost". This could also solve the changes and deletes
> challenges as
> the community sites could ping the central site when something has
> or been deleted as well.
I agree that it also spreads the cost, and it's a better approach.
However, it increases the work done by the sites, which might slow
My thoughts on mitigating this:
a. Don't. :^) Seriously, weblogs.com only had that problem when they
were wildly successful, with hundreds of sites to check. I don't
expect us to have that problem for a while.
b. Spread the load of collecting. Have more than one gatherer,
running in more than one place in the world. This is the way the old
Harvest project worked, gatherers were separate from brokers.
Still, this isn't as good as the ping approach.
> The ping could be a python script that gets executed from DCWorkflow
We don't have DCWorkflow on czo. :^)
> sends the central site the title, date, author, description (200
> or less), subject keyword(s) originating site name and url, permanent
> and whether this action is a creation, modification or deletion. The
> does some magic to create/edit/delete an object on the central site
> this information and submit it for publishing/acceptance. someone on
> site reviews it and publishes/accepts it.
Uhh, I'm not sure I want to approve that much content. If it "ping" is
a solution to a high volume content problem, then this moves the
problem to people instead of machines.
How many approvals per hour would you expect in this approach?
>> * Long URLs. How do we organize the linkbase resources on czo?
> how about that?
Great, except the camel case. :^) Also, it would require zope.net to
be transfered to this use. I'm in favor of that, but that decision is
beyond our control.
>> * Categories.
> I wonder if we can leverage the dmoz idea here? or perhaps incoming
> submissions are self-classified and if an admin wants to change it she
It's probably the most scalable approach, but I don't think the CMF
will support distribution of categories. Hmm, or perhaps I'm looking
at your approach wrong.
So the idea is that there might be a Templating category, with a ZPT
subcategory, and that might be turned over to a category owner. That
person could then subclassify? And you'd use path indices or topics or
something to assemble the data (since you aren't in a containment
FWIW, last May, the central conclusion we arrived at regarding
Jeffrey's statement about the content org problem was the need for
sections and section owners. That is, divide the big zope.org content
pile up into smaller piles, and make someone responsible for those
>> * Needs to work with czo.
>> * No migration issues for nzo.
> Gee, these are some pretty tough constraints. would be easier to start
It's always easier to start from scratch, which is one of the reasons
we're in the situation we're in.
I'm pretty sure that czo can support many of our goals. The major
problems will arrive later, when/if we're wildly successful.