[aclug-L] Re: volunteers

[Tom Hull <thull@xxxxxxxxxxx>]

Clint Brubakken wrote:
> 
> I disagree with that.

Disagree with what?

> As its already written in Zope, we can extend and change it, with out
> rewriting the whole thing.

The content can be recovered and reused regardless of the tool set.
That's part's easy. Is there so much customer software development
(i.e., not including zope itself), and is it so precious, that redoing
or transplanting it is an insurmountable burden? (Not that I can see.)

> Another advantage is the I know several of the commitee, already know
> zope and as there already involved in working with ACLUG I would think
> they would also help with the website, and can help teach others.

A corresponding disadvantage is that I don't know zope (nor python),
whereas I do know openacs (tcl, sql), and thus far I've found zope to
be pretty damn opaque. And I hate to say this, but your presentation
on zope didn't help me one bit.

I'm trying to keep an open mind on this: I've just installed zope; I'm
starting through "The Zope Book"; but at this point it's still opaque.

> Also ACLUG has  books in the library about Zope and Web Programming in
> Python

Zope definitely has more extensive 3rd party documentation, more second
sources for support, more add-on modules/products (some of which we have
to exclude for $$$ reasons), more users. (OTOH, Greenspun's book is
actually readable -- the only technical book I've read cover-to-cover
since the 1st edition of Stroustrup's C++ book.)

> And a completly biased opinion, is that I know and like zope.

Thanks, that's a point in zope's favor.

> I don't know much about OpenACS so I can't argue its merits vs Zope, but
> I can tell you things I like about zope.
> 
> Everything can be done through the web (TTW) or via ftp.
> 
> It has built in user permissions and roles and different access levels,
> and a built in authentication system.
> 
> It has several prebuilt products, including wiki's.
> 
> and the people in the #zope channel on openprojects are actually helpful

No obvious big advantages here over openacs. I don't know what the outside
help for openacs is like, since the code is clean and simple enough that
I've never been compelled to find out. I don't know of an openacs wiki,
but it's pretty obvious how to integrate wiki code, and there would be
some advantages to tying it into the member database.

How would you implement something like Ryan Hunt's request (browsable,
searchable database of member information, member-controlled) in zope?

> On Fri, 2002-02-08 at 14:46, Tom Hull wrote:
> >
> > Jonathan Hall wrote:
> > >
> > > The existing site uses Zope, which is much like OpenACS in many ways.  I
> > > believe Zope is actually a much more feature-rich application than 
> > > OpenACS,
> > > although OpenACS is probably more 'mature'.  Unless there's a good reason 
> > > to
> > > switch to OpenACS, I suspect Zope is the better way to go... simply 
> > > because
> > > we have a server on an OC-3 already running zope :)
> >
> > I don't buy the argument that we should use Zope because it's what is 
> > already
> > in use (which we've pretty much agreed is wanting). I also think that the
> > hosting question should be separate from tools/content development (although
> > the latter may impose some requirements that limit hosting choices; traffic
> > and dataset size also impose requirements).
> >
> > The real question is whether Zope is really better (multifaceted word) than
> > OpenACS for our requirements. At this point I don't know Zope (or Python), 
> > and
> > would appreciate any insights from anyone who has experience with Zope 
> > and/or
> > OpenACS.
> >
> > The other thing is to work out a list of things people would like to see on
> > the website.
> >
> > > There was some dicusssion on the committee list about moving the server 
> > > back
> > > to Kansas, and some suggested leaving it on the OC-3 is best.  I'm still 
> > > not
> > > entirely convinced, though.
> > >
> > > I think if we have people willing and able to work on the software, we 
> > > sorta
> > > need the server where they can use it... Perhaps we can get a good
> > > colocation deal from a local ISP?  Maybe iWichita, Websurf, Datility?
> > > Something that would give us enough bandwidht, but also local access 
> > > if/when
> > > necessary?


-- 
/*
 *  Tom Hull * thull at kscable.com * http://www.tomhull.com/
 */
-- This is the discussion@xxxxxxxxx list.  To unsubscribe,
visit http://tmp2.complete.org/cgi-bin/listargate-aclug.cgi