[webdev] Re: evolution

["Dale W Hodge" <dwh@xxxxxxxxxxxxxxxx>]

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

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

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

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

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

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

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

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