Complete.Org: Mailing Lists: Archives: discussion: February 2002:
[aclug-L] Re: volunteers
Home

[aclug-L] Re: volunteers

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: discussion@xxxxxxxxx
Subject: [aclug-L] Re: volunteers
From: Jonathan Hall <jonhall@xxxxxxxxxxxx>
Date: Fri, 8 Feb 2002 15:38:13 -0600
Reply-to: discussion@xxxxxxxxx

I do have experience with Zope.  I considered Zope and OpenACS for a project
I was doing, and chose Zope, as it seemed to be a much more comprehensive
product.  I then did my project in Zope, which is where my first-hand Zope
experience comes from.

I don't have first-hand experience with OpenACS, aside from the comparison I
made when I ended up choosing Zope.

And to summarize that comparison, OpenACS seems to be a more "complete"
product for "online community" development.  Zope is, as many non-commercial
Opensource projects, a much more extensive product that can be used for much
more than "online communities", and interfaces well with a much wider range
of third party applications (i.e. MySQL, PostgreSQL, I believe even Oracle
and other DBs) not just PostgreSQL (I believe that's what OpenACS uses). 
And it interfaces with many, many other things, too (I just used DBs as an
example), and comes with modules and .zexp packages (Zope project packages)
for many functions.  Yet, Zope, also like many non-commercial Opensource
projects, has many rough edges.

-- Jonathan



On Fri, Feb 08, 2002 at 02:46:40PM -0600, 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

--
Floppy disk tip #5: Data access time may be greatly improved by cutting more
holes in the diskette jacket.  This will provide more simultaneous access
points to the disk.
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  Jonathan Hall  *  jonhall@xxxxxxxxxxxx  *  PGP public key available
 Systems Admin, Future Internet Services; Goessel, KS * (620) 367-2487
         http://www.futureks.net/  *  PGP Key ID: FE 00 FD 51
                  -=  Running Debian GNU/Linux  =-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-- This is the discussion@xxxxxxxxx list.  To unsubscribe,
visit http://tmp2.complete.org/cgi-bin/listargate-aclug.cgi


[Prev in Thread] Current Thread [Next in Thread]