[RFC LONG] Ideas for a simple News Management System

Joachim Beckers jbeckers at linuxfromscratch.org
Mon Jun 20 07:02:43 PDT 2005

Anderson Lizardo wrote:
> Actually, I had an idea for modifying/updating news items through
> e-mail, but I skipped it on the RFC because I really wanted to avoid
> increasing complexity to the code by implementing a feature rarely used
> (at least IMHO).
> It basically would work as follows:
> Resend the news post to the news-* address with the _same_ Subject of
> the original e-mail. manage_news2 would then detect a previous news item
> with the same subject and overwrite the old post with the new one (and
> re-render the website accordingly). Maybe some flag would be necessary
> (e.g. putting the commit ID on the subject as you proposed) to handle
> the case where the poster mistakenly posts a news item with the same
> Subject of a previous news item.

Looks basically like the same mechanism, only does mine involve svn,
while you presume that newsitems are only stored on the webserver. Also,
I think the commit ID is absolutely _necessary_ (in both cases), because
subjects can not only mistanely be the same. We've had more than one
"Newsserver Off-line" and "New BLFS Editor" newsitems before, so
identical subjects will no doubt occur in the future too.

> The problem I see with posting a diff is that:
> - How do we would create such diff if the poster wrote the news post
> directly on his/her MUA;

True, this wouldn't be possible when news is stored on the webserver
only, and not in svn. I would however create a repo for newsitems, so
that a newsitem can be corrected by doing:
   $ svn co http://svn.lfs.org/news/newsitem-[ID].txt
and then editing newsitem-[ID].txt, creating a diff and posting that.

This would be a safe and "un-error prone" mechanism. Only admins (and
the manage_news2 script ofcourse) need write acces in the news repo and
svn will detect certain failures for us (for example when generating the
diff). Apart from that, it will give us a history of the newsitems (not
in a way of storing them, but in a way of stroing what has changed)
which could come out handy.

> - How do we guarantee the diff stays intact, i.e. is not wrapped by the
> MUA (although sending as an attachment would fix that)

Yes, attachments are a solution, but what I'd like to add is that the
same applies to what you had in mind. In fact that's the only major
problem I see with the whole idea of sending newsitems by mail. Not all
mailapps will produce the same output (of course they should, but then
just think of OE's quoting behavoiur and you know it's true... :-)), so
manage_news2's mailparser will have to be able to understand some

> Thanks for your suggestions, we'll take them into consideration :)

I'm glad I can help...

> PS: For now, we should focus on implementing the 1st stage, maybe the
> 2nd one even proves unnecessary...

No problem, go ahead ;-)
The new site looks great btw, much better than before. Very nice work.


More information about the website mailing list