Re: Projects

["Aaron D. Turner" <aturner@best.com>]

-----BEGIN PGP SIGNED MESSAGE-----


On Thu, 5 Nov 1998, Lenz Grimmer wrote:

[SNIP]

> OK, here a my thoughts about using a DB:
> 
> - Why? - Simply, because I don't think you would want to maintain all
>   these pages manually. By extracting the content from a database, you
>   just have to set up some templates and let the database do the content.
>   This will make it more flexible for us. In addition to that, a DB is
>   searchable by it's very own nature :)

But not searchable via ht://dig.  We *need* fuzzy logic if we want to
attract newbies who don't know how to spell things.
 
> - What? - Well, here we go. Which areas of the site should be stored in
>   here and in which format? Would it make sense to store data about
>   mirrored pages in there? Or should this part be viewed seperately?
> 
>   IMHO it would make sense to migrate the RHLUFAQ into a DB and extend
>   it to be a general FAQ Database. Maybe you can apply some kind of
>   attributes to each Q&A-pair, like: "applies to the following
>   distributions, keywords, category, score for usefulness, etc.), just
>   like the current RHLUFAQ has, but more flexible.
> 
> I've just been toying around with the RHLUFAQ. If we open it up to be not
> so RH-centric, I could migrate the articles from our current support
> Database into it. Funny, as far as I know, we are currently trying to
> create something similar for our internal purposes. I wonder if it might
> be possible to get some more help from my people here to pull on one
> string. I have to check out the status of our work here.

Sounds like a plan.

[snip about slashdot code]

> > I've already written some CGI's that do this for the RHLUFAQ.  
> > Currently they have the following features:
> > 
> > 1) Form with specific fields & checking for "required" fields
> > 2) HTML'zation of http, ftp, and file links
> > 3) Authenticated users can have their entries added to the index
> > immediately and without admin intervention.  Even supports replacing a
> > FAQ.
> > 4) Support for multiple mailboxes which can then be used to generate FAQ's
> > (people can forward from mail lists and newsgroups).
> > 5) "Smart" temp files.  Submissions from users that need to be added to
> > the index by an admin are correctly formatted, and have the next available
> > filename pre-assigned.
> > 6) All updates generate an email to the admin.
> > 
> > The features I haven't had time to do yet are:
> > 1) Support deleting of email from mailboxes
> > 2) Web based administrative accept/deny form to add proposed entries to
> > the FAQ.
> > 3) Support for asking of questions
> > 4) Better authentication method
> > 
> > Right now what I have is pretty solid (ie it works and doesn't seem to
> > have any bugs), and could pretty easily be adpated to the KB I think.
> 
> Do you think it would be possible to make it based on a database? How do
> you store the data right now? Flat files? Which Language do you use?

It's all Perl and files are stored as the HTML files themselves.  Fill out
form->fully formatted HTML entry.  If we used a Perl SQL module it should
be a piece-o-cake to output into a DB- though I'm still not sure I like
it, unless someone knows a fast fuzzy logic module???

[SNIP SQL comparision & joins]

> [FRAMES]
> 
> > Obviously this is a very subjective preference.  We also have to consider
> > the advantages of frames and non-frames technically:
> > 
> > 1) Frames allow you to "keep" a top level menu for easy site navigation
> 
> You could do the same by using template files which include the navigation
> bar.
> 
> > 2) Frames don't force you to re-load common parts of pages (like menus)
> > over and over again, which is good for slow connections.
> 
> Agreed - but this depends heavily on the size of the menu items and
> images. These items would be cached by the browser anyway.
> 
> > 2) Frames are poorly supported in Lynx
> 
> Indeed :)
> 
> > 3) Frames allow you to open a page on another site, but keep the user on
> > your site.  This allows people to avoid the "back" button and prevents
> > problems with HTTP redirects which prevent people using the back button.
> 
> True. An alternative would be opening a new browser window for each
> external link. I admit, this is a point, where frames could actually be
> useful.
> 
> > 4) Many people don't like frames (I think this is becuase so many sites
> > did them in a confusing manner).
> 
> See Jakob Nielsen's Alertbox for December 1996: "Why Frames Suck (Most of
> the Time)" on http://www.useit.com/alertbox/9612.html for more info. I
> really recommend this site when in comes to usability issues.
> 
> > 5) For the Red Hat Linux User's FAQ, people chose the frames version over
> > the non-frames by 4:1.  (Probably because the non-frames version sucks in
> > graphic browsers.)  People also prefered the JavaScript pages over the
> > non-JavaScript pages by the same margin (I guess people like mouse-overs
> > :-)
> > What I'm trying to point out is that there are good and bad reasons to do
> > frames.  Let's just choose the best format for *our* site-- who cares what
> > everyone else does.
> 
> Should we vote about this subject?

Sounds good- but everyone should read that article on frames first.

- -ADT


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBNkH51zM3jpXy1kJtAQFxgAQAoFGu9NM3TQLj2MMOj8CcGCGHXObMbO7L
1kufh6B1jl4qtnz2aqcussqLgLojvl3iddQ+RAv8iUQ3TAU+ajVM8jXByDWg18JI
G1CmnPeNfDtXZGpQx5/roN19O6gTm2t2tHCsvenPVcMuXudGvrHA3Hroxf6TFw++
euS2lEKi8R8=
=Ke1m
-----END PGP SIGNATURE-----