[ZWeb] Re: Zope.net

[Paul Everitt]

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:
>>
>> http://www.zope-europe.org/articles/200301/czolinkbase
>
> Retrieve the RSS listing from each site
>
> This could get expensive. I'm thinking of the example of weblogs.com 
> which
> checked all the weblog sites every hour i think to see if there were
> updated. What about a reverse approach, where community sites "ping" 
> the
> central site when they have something new they want added? This would 
> spread
> out the "cost". This could also solve the changes and deletes 
> challenges as
> the community sites could ping the central site when something has 
> changed
> 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 
adoption.

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 
> and

We don't have DCWorkflow on czo. :^)

> sends the central site the title, date, author, description (200 
> characters
> or less), subject keyword(s) originating site name and url, permanent 
> url
> and whether this action is a creation, modification or deletion. The 
> script
> does some magic to create/edit/delete an object on the central site 
> with
> this information and submit it for publishing/acceptance. someone on 
> central
> 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?
>
> zope.net/Sites/ZopeZen/1
>
> 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 
> can?

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 
hierarchy).

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 
piles.

>> *     Needs to work with czo.
>> *    No migration issues for nzo.
>
> Gee, these are some pretty tough constraints. would be easier to start 
> from
> scratch.

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.

--Paul