MMSS's NEWS support:
====================

 News archives for pages, section, or sites, are handled as *ar* archives
in which each file in the archive is a separate news item, named by the
date it is for- in the form YYYY-MM-DD.

--------------------

 A program could be made to create new news items for an archive, with
the options to edit preexisting items or delete them.

 To edit old ones:
-Take date for item to edit
-either "print" or "extract" that file to some temporary location, edit
 it, then use "replace" on that item.

 To create new item:
-Get today's date
-If time is before 6AM, ask if we want to use *yesterdays* date instead
-Convert date to our YYYY-MM-DD format
-create blank file to edit, and edit it
-Alternatively, we *should* check if an item for today already exists,
 and if it does, see "edit old ones" above :P
-If it didn't exist, put it in the archive (could use "q" instead of "r"
 if it doesn't exist, but this causes uncertainty)

 To delete existing item:
-Take date for item to delete
-Print it to STDOUT for user to confirm this is the right one
-If it's longer than 1/2 a screenful, crop it and give user option to
 see full thing through less. Or just use "less" anyway?
-If user still wants to, delete it.

 Now, the exciting bit!
 To create news pages:
-Decide how many pages news is going to be spread across- should there
 always be an archive for the oldest stuff? Perhaps for some pages there
 could be an option of simply *ignoring* oldest stuff...
-Decide how much should be on the first page, in terms of items and
 bytes. EG: we could have 3 items, but those 3 could be very big or very
 small. Hmm...
-Count number of items and total archive size
-From all this, work out how much should be in the archive (or the set of
 items to ignore, if appropriate), and how much should be on each other
 page.
-We should be able to get the items in chronological order by doing:
 ar t newsarchive |sort (to be certain)
 (would probably use "sort -r" too, to get reverse latest-first)
-Using our counts and our list, we can create an index of which items
 will go into which page. Possibly store this index in the directory
 alongside the news archive.
-FINALLY for each page, we include the items appropriate to it.

-----------------------------

 QUESTION: In cases where news spans several pages, we'd want the pages
 for older news (plus the archive page) to have each item a separate box.
 HOWEVER: For the first page of news, the news would often be one box
 of several others!
 SO, what do we do here?
 1)Just have all news items of the first page concatenated into one box
   with the appropriate dates listed inline.
 2)Have each news item on the first page in its own box, with the box
   title either just the date (as on later pages) or News: Date, or
   News: Date for the very first item and just Date for the older ones.
   Not sure if we should care if there's other boxes before or after
   the news boxes.
 3)Have just one box for the news items on the first page... but with
   *subboxes* for each item!! This might be horrible though.

 I'm not really sure. At this *minute*, I'm favouring option (1), but
 with some sort of separators between each item. Perhaps little
 pictures, or HRs or something.

------------------------------

 I've also been thinking MMSS should support a way of listing images
that each page has, so that it can work out some sort of *reference
count* and decide when it should delete images from the server! If
we do this, some code should be made to *also* find image references
in the news items too! NB: I currently think image references in
the pages should be done with MMSS macros; in this way, MMSS can
automatically fill in twiddly details like image inlining and the
image dimensions, which I've been forgetting (and are apparently
useful to browsers on slow connections). This is mostly a topic for
discussion elsewhere though. All we need to remember is that it'd
be necessary to be able to extract the references from archives.

--------------------------------

 ALTERNATIVES:
 News items could also be stored in other ways, such as loose files
in an appropriately named subdirectory (with filenames equal to those
in an equivalent ar format news archive), or loose files in *the same*
directory as the pages they're for, but named slightly differently
-eg index.news.2004-02-30 etc...
 This is one way of doing things, and would prolly be more flexible
in terms of what editor you can use, but makes everything horrible and
MESSY with all those files lying around. I think *for the time being*
I'll just implement the *ar* method and leave others for later.

---------------------------------

 Page filling:
 Discussed earlier in very little detail. Not sure of best algorithm
for this. *Main* thing is that the last (archive) page should contain
somewhere along the lines of *half* the content of the news- whether
in bytes or items. Uh, probably in bytes actually. First page should
contain a *fixed* amount, probably in items, but not sure. Pages
in between should contain increasing amounts as we get closer to the
last page- because readers should be *less* interested in the distant
past, and we want to have the most frequently viewed pages to have
the *least* content to reduce bandwidth usage.

 Proposed page filling algorithm 1:
 -Page has a minimum size (in bytes) and a maximum size, plus a
  maximum number of items.
 -Place items on page until either the minimum size or the maximum
  items is reached.
 -If we're below both maximum size and maximum items, add items
  that *will not* take us above those limits.


 With such an algorithm, and the total capacity of all items, we can
work out roughly how much would go in the archive (capacitywise), then
after working out how many items would go on the first page (which would
have the limits user-specified), we can work out how much capacity
should be split between the in-between pages, and start dividing it up.
We should set minimum size to only slightly less than the desired size,
and maximum size to maybe 5% more than the desired size. As we'd be
filling the more recent pages first (which we want to contain *less*),
it makes sense to not try filling them too fully.

 Desired size of middle pages: Page N should contain almost as much as
Pages 1 to Page N-1 put together (except for page 2, which we'd expect
to contain *more* than page 1 of course!)... Hold on, that doesn't
quite add up :P
 Instead... 2nd page should contain no less than 1/4 as much as the
page before the archive (should we call that the "attic" page instead?),
which naturally should contain less than the attic page (remember that'll
try to have 1/2 the total capacity!). The 2nd page *also* should contain
more than the first page, unless there aren't enough items to allow
for this!
 Pages after page 2 should try to contain more than page 2, again unless
there aren't enough items to. Pages that don't have *enough* items
should just contain as many as are available, and any pages *after*
that should be blank/empty (that includes the attic!).

 When all the other pages have taken what they want, the attic page
should get the rest. If there's lots of content, that'll probably
be around 50% of it, but that depends.

F=first page, 2=2nd page, Px=page x, A=attic, T=total

2>=F (try)
F+2+P(3...N)+A==T (definitely!)
A=T/2 (try)
Px>=Px-1(try, for x>2)
PN<=A (try)

Lets see... We can get total from summing the byte counts of each item
from the news archive; We can work out how much would be outside of the
attic by doing total/2; We can work out how much would go on the front
page when we try to place it. Then we can work out how much would
be split between te remaining pages by doing (total/2)-(first page).
For the moment, we work in terms of "desired amounts"
We work out how much could go on the second page by seeing if we can
get a value higher than first page, but small enough to fit in the
remaining total. We do equivalent for each of the remaining pages.
Then, the last page almost certainly should be less then the attic,
but we need to make sure that the total is used up, and that the
last page is no more than 4X the 2nd page...

Thought: simply Px=xYP2 where Y is some constant that is less than 2 or
so to allow for PLast<=4P2... something like that?

