[RFC LONG] Ideas for a simple News Management System

Anderson Lizardo lizardo at linuxfromscratch.org
Fri Jun 17 19:17:15 PDT 2005

Jeremy Huntwork wrote:
> I think modifying the news items is going to be a necessary feature.
> Consider - what happens if someone submits a news item containing a URL
> and the URL is incorrect/broken? Or there are spelling mistakes that
> were missed, etc? We will need to adjust those somehow, so what will be
> the method of doing that?

The traditional one: edit the HTML/RSS produced by manage_news2
(possibly stored on the repository or directly on
/home/httpd/www.linuxfromscratch.org) and fix the problem.

As I said, AFAIR news item modification is rare on our current system.
Usually, when someone prepares a text for an announcement, he/she makes
at least a minimal revision to the text before posting it.

Additionally, we can always post errata news when the issue is more than
a few typos. I often see news sites doing this (specially for
announcements), or then modifying the original news item with a big
"Update:" on it.

Anyway, how many people read a news item more than once, looking for
updates? :) IMHO posting a new one explaining the mistakes is more visible.

> Also, I understand that much of the goal with this new concept is
> simplicity on the user-end. Make it simple for authorized developers to
> submit an announcement. However, part of the problem with the current
> setup was the complexity of the back-end and few people around that
> understood how that back-end worked. So when something breaks, it's a
> scramble to find out how to fix what's broken. I think that's something
> we should try to avoid as much as possible with the new setup. So, in
> that sense is it overall easier to go with something like the mail
> submission you're proposing, or editing text files in the repo?

Imagine this situation:

manage_news2 is the "frontend".
"manually editing text files" is the "backend".

You can use the backend directly (e.g. for doing complex formatted HTML
or modifying news items) or the frontend for an easy-to-use (and more
accessible) interface.

Regarding the system's complexity, I believe better documentation (the
current system has only the inline POD and "--help", but no overall
usage instructions) and good comments can simplify things a lot.
Personally, I don't think we can guess complexity before having a
working implementation, as there are systems which either have (a) both
easy to use interface and simple code, (b) easy UI but complex code or
(c) bad UI _and_ complex code.

> Note that I'm not trying to be overly critical of your idea, it is a
> pretty neat one, :) - just trying to think out all the relevant points
> so that in the end we have the best setup for our needs/circumstances.

No problem, I certainly take your comments as constructive :). From what
I understand from your comments, it's possible that the "e-mail gateway"
input layer can turn the code complex, right?

In this case, I suggest a two-stage modular approach: we first implement
a simple "Formatted text -> HTML/RSS" parser which would receive as
input a file like:

Title: News Title
Author: Author Name # Optional, defaults to the commiter
Date: 2005-06-17 # Optional, defaults to the file's timestamp.

[content goes here, formatted with Wiki-like syntax]


And then, upon commit, (using our already running post-commit
mechanism), convert this text to news items and RSS.

A (possibly optional, if the 1st stage proves complete enough to fulfill
our needs) second stage of the implementation would implement the
email-driven input layer, which would finish the system:

MIME Message -> Formatted text -> HTML/RSS

Anderson Lizardo
lizardo at linuxfromscratch.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfromscratch.org/pipermail/website/attachments/20050617/00d83ed1/attachment.sig>

More information about the website mailing list