Re: Projects

[Lenz Grimmer <grimmer@suse.de>]

Hi,

On Wed, 4 Nov 1998, Aaron D. Turner wrote:

> > Me too!  I just know we need a DB and a  search engine.
> 
> Well then lets work on it. 
> 
> First: *WHY* do we need a DB?  What is it's purpose?  What is the
> goal? What problems does it solve?  How does it make our lives easier
> or the site better?  What can it do for us and the end user?
>
> Just to clarify, I'm not saying we don't need one.  But I do know we can't
> design it without knowing what it is for! :-)  When you can answer those
> questions you'll be well on your way designing the DB.

[SNIP]

> Good.  What else can the DB do besides what I have listed?  How would you
> impliment it?

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

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

> > > Maybe we could use part ot the "ask slashdot" code for this?
> > 
> > I was kind of thinking that.  I'm not sure how complicated it would be
> > to integrate.
> 
> I don't think that will work.  The basic structure of the Ask Slashdot
> format is more like a message board than single entry FAQ's... not to
> mention the question submission is via an email address to a human.

OK, I see.

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

> > > Even though PHP has matured a lot, I'd vote for Perl in combination with
> > PHP is cool, but so is Perl.  Either is fine with me.
> 
> Perl is fine with me since I don't know PHP. :-)

Since I suspect, that the current RHLUFAQ is also done in Perl, we should
stick to this.

> > > DBD/DBI and mod_perl. Did we already decide about the RDBMS? I'd recommend
> > > mySQL - it's free for use as a WWW-Backend.
> > 
> > Question:  Does mySQL support SQL joins?  I think that feature will be
> > necessary.  If it does, we're probably set.  If not, it will probably be
> > Postgres.
> 
> Don't forget the performance hit related to a join.  If we can avoid
> it, it would be nice.

mySQL has some pretty good optimizers for this stuff. It's pretty fast,
compared to mSQL. See

http://www.mysql.com/Manual_chapter/manual_Introduction.html#Features

for a complete list of features.

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

Bye,
	LenZ

------------------------------------------------------------------
 Lenz Grimmer                                           SuSE GmbH
 mailto:grimmer@suse.de                       Schanzaeckerstr. 10
 http://www.suse.de/~grimmer             90443 Nuernberg, Germany