[webdev] Re: ACLUG Website - which way to go...

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

> -----Original Message-----
> From: webdev-bounce@xxxxxxxxx [mailto:webdev-bounce@xxxxxxxxx]On Behalf
> Of Tom Hull

> I don't think the decision as to which website technology we go
> with should
> be based on which kit has the niftiest modules. (If it did, I have another
> dozen modules up my sleeve.

I know OpenACS has a bunch of modules. But are they really useful?  So far,
people don't seem to be using the features currently implemented. That's the
discouraging part of this whole effort.


> On the other hand, I've run into
> technical snags
> on getting RSS feeds working.)

I've seen (and have) a xml parser written in perl if that would help.

> I think the decision should be made on the
> following criteria:
>
>   1) Who's willing, eager, and competent to work on which platform?
>
>   2) What's the big picture concept for the website?
>
> In my mind, #1 is critical. In that case, my position is that if I am
> the only person who is willing/eager/competent to work on openacs, then
> I'll vote for postnuke.

One thing I'll admit to is that a programmer I'm not. If I work long enough,
I can usually follow the logic, but could never really write anything
usefull. I can usually figure out how to make things work, even when they
are poorly documented.  I don't mind managing a site as long as I don't have
to jump through too many hoops to get the day-to-day stuff done. My personal
feeling is that a site should occasionally have a graphic makeover to keep
it interesting.  In that vein, it should be easy to change the look and feel
without a major amount of work. I'm hoping that OpenACS can be made to work
this way.

> As for #2, I think the alternatives are:
>
>   1) My concept for the openacs system was to provide two main things:
>
>       a) an extensible repository of help information
>       b) a set of user services and inter-user communication tools
>
>      There are lots of other things one can do with openacs, but these
>      are things that it excels at (albeit with a little extra work).
>      The emphasis here is, I think, community building.

I suppose this is something I just 'don't get', the community building.  I
guess I don't understand what is trying to be accomplished.  Can you give me
an example?

>   2) The typical use (therefore what it is most fit for) is to provide
>      a news portal. The emphasis here is, I think, information access.

News, events, and technical resources, I think.

> I think that if you find #1 more attractive, openacs is the system of
> choice; OTOH, if #2 is the thing that most interests you, then postnuke
> is a system that will give you that with significantly less work.

Less work is very true.  The question becomes whether we are giving up
anything important to get that less work.

> That "less work" is a significant issue. As Dale has pointed out, I
> started working on the openacs system six months ago, and it hasn't
> gotten very far. A lot of that is my fault -- I've had a number of
> distractions, and haven't actually been able to put a helluva lot of
> work into the project. I also see more distractions on the horizon,
> so maybe you should make a choice that is less dependent on me.

Well, you weren't supposed to be the only one working on it. But for
whatever reason, it seems things tend to fall on one person's shoulders. As
you've probably figured out by now, we're working with a very apathetic
bunch.

> On the other hand, I want to point out one more thing: the postnuke
> approach depends on adopting beta software which will certainly be
> changing frequently and will inevitably force you to go through any
> number of upgrade cycles.

Although derived from a stable v5.x release, PostNuke calls their project at
.7 Alpha level, Beta won't happen until the .9 series. But given the number
of sites that run the software (it's one of the most widely developed and
used projects on SourceForge), I don't have a problem with running it. To
date, they have been careful to make it possible to upgrade from one
revision level to the next without much drama. There's nothing that says we
have to upgrade as long as we're happy with the current feature set.  Since
I run PostNuke on my own sites, I'll be testing upgrades on a test site
before updating production machines.

> By contract, the openacs approach starts
> with mature software that is not being updated: while this sounds
> worse at first (no freebie new features) it is in effect a much
> cleaner and more stable platform to build on. (We can, of course,
> port new features from other systems on an incremental basis, but
> we'll never have to go through a total system port, which can be
> seriously painful, especially if we develop our own things.)

I think as long as you write to the PostNuke API, changes shouldn't be too
painful.  I understand that there have been a few changes to the API to
date, but generally the changes have been well documented. The biggest
change that I've heard of has been the removal of global variables from the
code.

> I think that it is probably the case that Dale's proof-of-concept
> system is mature enough (as is the openacs-based system) that we
> should start moving toward a decision here. Let's thrash that out
> in email here on webdev, then have a meeting to finalize a decision.
> OK?

I keep hoping that users will get involved and give us some feedback. So
far, people seem to be lurking, but not really trying things out and giving
useful feedback.  At this rate, it's going to come down to whatever we can
work out between us.

--dwh

---
Dale W Hodge - dwh@xxxxxxxxxxxxxxxx
Vice Chairman & Secretary - info@xxxxxxxxx
Air Capital Linux User's Group  (ACLUG)
---