[ZWeb] Re: Zope.net

[george donnelly]

[Paul Everitt]
> 
> 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.

but it would be doing it "right", which would be better in the long term.
and i don't think it would slow it that much because we could put out a
sample script that would work for many people out of the box.

if the central site has to do everything then its going to slow down things
as well. if the cost is spread then the central site can get going faster
and the more savvy users will get on board quickly as well and be able to
help the less savy users. maybe?

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

good point, but why not plan for wild success from the start? esp when it
will involve less or the same amount of work and be more stable and
inexpensive?

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

but isnt this more expensive and more complicated?

> 
> 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. :^)

Why does this have to work on CZO? Why is that a requirement?

I'm not sure that this is possible/practical given this contraint.

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

good point, maybe we don't need the approval process. how about new
community sites must get approved and then they can freely ping new content
onto the community site as they want? an admin could always remove any
objectionable content and/or suspend any community site that consistently
pinged in objectionable content, should this happen.

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

sorry, what's the camel case?

zope.org could equally be used.

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

maybe the dmoz idea does not apply. what about letting content auto-classify
itself and including this as an index in the catalog. then lists by subject
can be dynamically created from the catalog and a subject hiearchy can be
simulated without the need for a real hierarchy, moving content objects
around or any new ownership systems.

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

<-->
george donnelly - http://zettai.net/ - "We Love Newbies" :)
Zope Hosting - Dynamic Website Design - Search Engine Promotion
Yahoo, AIM: zettainet - ICQ: 51907738 - e:george@zettai.net