[webdev] Re: evolution

[Tom Hull <thull@xxxxxxxxxxx>]

Dale W Hodge wrote:
> 
> > -----Original Message-----
> > From: webdev-bounce@xxxxxxxxx [mailto:webdev-bounce@xxxxxxxxx]On Behalf
> > Of Tom Hull
> 
> > > I'd really like to find something that would be easy to
> > maintain not only by us,
> > > but by whoever takes it over in the future. I don't see us having many
> > > volunteers if the system requires learning a bunch of new stuff
> > to operate.
> >
> > This could be a debilitating requirement. I'd rather shoot for something
> > that we really want, and plan on spending some time documenting how to do
> > that.
> 
> I just don't want the same thing to happen again, building the site in
> something most of us barely understand so therefore it doesn't get utilized
> to it's full potential.

Understood. But I think the only real way to handle it is to have more people
involved at each step, ask questions, and write down answers.

> > Despite my recent lack of productivity, I figure I can put a good deal of
> > development time into this over the next 6-12 months.
> 
> I'm assuming you mean that to fully implement all the feature will take that
> long.  Surely we could have something more basic working much sooner, right?

Right. It should take a couple of days to configure a machine, set up cvs,
openacs, aolserver, postgresql, htdig, some other stuff. I don't know much
about ssh, and I've never gotten aolserver ssl set up, so I'll need some
help there. Could stretch out, but not much. Then a couple more days to lay
out some skeletal content. I'm a little shaky on some acs concepts like
groups and content sections, so it could take a bit longer to sort them
out. But it should give you user management, the ability for select users
to add/structure content, ability for users to comment on content, forums,
calendar, news, several other useful ready-built modules. Logs and backups
will take some extra thought.

John Alexander is probably the best choice right now for connectivity -- this
would be at your office, John?

> > I think that means that we can build some
> > interesting things.
> > We can also plan for everyday maintenance to be straightforward
> > -- especially
> > things like posting news, editing static text, adding comments, etc.
> 
> That part needs to be easy enough that we can assign anyone to do it, so it
> doesn't fall on just one person's shoulders.

With possible exception of static text, these things are all web interfaces.
Probably static text also. Not sure what the granularity of the user grant
system is (I think it's tied to groups), but I imagine it should be flexible
enough (groups should be arbitrarily flexible; e.g., give calendar to the
Calendar group, and assign whoever you want to that group).

> > I'm leaning pretty strongly against zope for this -- it looks like a tough
> > learning curve, at least for developing new modules/applications.
> 
> Zope isn't the most intuitive thing to learn. I'm sure it can do all manor
> of wonderful things, I just have a hard time understanding how to do some
> things that really should be simple. It's definately not my choice for
> webserver.
> 
> > Openacs
> > has a lot of functionality, and the tcl scripting and sql are pretty easy
> > to get a grip on. (Tcl is a lot easier than perl, python, etc., and works
> > pretty good for just manipulating text, which is pretty much all
> > the dynamic
> > content does.) Hacking in new things is pretty straightforward.
> 
> It's been a while since I looked at Openacs, but at least I could understand
> the underlying code.

I've started a cross-reference of all of the functions and variables, and all
of the aolserver and tcl support functions.

> > The other approach I'm pretty open to would be to hack something
> > from scratch
> > mostly using php (probably apache and postgresql). The nice thing
> > about this
> > is that you start out knowing everything that's there -- no
> > clutter. Then we
> > could take concepts from other pieces, translate them, hack them
> > in. Downside
> > is we get less out of the box, have more development churn, more
> > bugs, etc.
> 
> My preference would be to use the platform that offered the most pre-built
> functionality along with the easiest setup and maintainance. That's not to
> say we couldn't build something ourselves, but why re-invent the wheel if we
> don't have to?  We may find that ease to use and functionality are mutally
> exclusive, in which case we'll have to decide which gets priority. My vote
> is for ease of use.

I've been thinking about writing my own php-based web framework, but it's
mostly for a different set of users/websites (individual writers, not
communities), so this effort could be extended if folks really get their
noses bent out of shape over openacs. I haven't been hearing that, so
for now the plan of record is to try out openacs. OK?

> > > Before we actually build the new site, I think we should set up
> > a test-bed and
> > > see how it actually works in practice.
> >
> > I'd like to set up an openacs system along these lines. [snip] One should be
> > able to setup a local testbed, download the cvs code (and possibly the
> > database) and run locally to hack on new things.
> 
> That's along the lines I was thinking of.
> 
> > I have the dual-686 machine I mentioned; also an older 586 if you think
> > the former is overkill.
> 
> I would hope it's overkill. I'd rather be able to run on lower end hardware.
> It's much easier to come up with backup hardware in case of failure that
> way.

I'm going to try to configure the old P-166. Nice thing there is that I don't
have anything on it (well, NT's on it, but that can be fixed), so I can build
it to order, and won't miss it.

> > Someone got a connection? We could do some initial
> > setup here at the house, then move the machine to a connection.
> 
> I have spare IP's, just not a lot of bandwidth. I don't know what other's
> have. Even so, that may not be a real problem, at least during the test
> phase.
> 
> > >  * News feeds from various Linux sites & Tech sites
> >
> > What do we need to do this? I've seen some apps that do this, but haven't
> > looked at the nuts & bolts.
> 
> I need to investigate a bit further myself. The big thing now is XML:RSS.
> (Rich Site Summary)
> 
> > >  * Automated FAQ system. FAQ-O-Matic or something similar
> >
> > I listed several FAQ systems on the wiki. Could someone take a
> > look at them?
> > What's good/bad/ugly, etc. There's a FAQ-O-Matic in use at the San Antonio
> > LUG; I wasn't very impressed with it, but didn't look too closely.
> 
> I'll take a look this weekend.

Good. Thanks.

> > >  * A good search system. The option to feed the query to
> > >    Google, etc?
> >
> > We can set up htdig to run locally; could also set it up to digest remote
> > websites if we want.
> 
> That's what I was thinking.
> 
> >Google is a big business, but we can
> > front-end to them,
> > just don't have (i.e., can't afford) the update management.
> 
> I was just thinking of offering a way to pass the query to google if we
> can't find it locally. It might be a way to get people to search us first.
> 
> > >  * A maintainable links page.  We should link to all the
> > >    Major dists & their errata. Security updates should be
> > >    easy to find.
> >
> > One thing openacs has is link management that checks for broken links,
> > flags them in database, etc. Recovers from temporary breaks.
> 
> I think there's some opensource link checkers out there, I just haven't
> looked at them. It's something else I should add to my list to look at.
> 
> --dwh
> 
> ---
> Dale W Hodge - dwh@xxxxxxxxxxxxxxxx
> Vice Chairman & Secretary - info@xxxxxxxxx
> Air Capital Linux User's Group  (ACLUG)
> ---

-- 
/*
 *  Tom Hull * thull at kscable.com * http://www.tomhull.com/
 */