Subj : Time periods and procedures for ELIST - Changes
To : Paul Hayton
From : Vincent Coen
Date : Sat Feb 12 2022 11:31 pm
Hello Paul and every one!
Sunday February 06 2022 17:10, you wrote to me:
> On 03 Feb 2022 at 05:57p, Vincent Coen pondered and said...
VC>> Change 6 months to 12, Change four warning and a delete warning
VC>> to one warning and the delete warning so this will give a total
VC>> of 15 months from last update submission before removal as
VC>> against 11-12 months.
VC>>
VC>> Gives a little more time to assess if the feed is broken or the
VC>> Echo has left the farm - no longer fit for purpose etc, pick your
VC>> options :)
> I would allow a listing to remain published for 12 months but issue a
> warning to renew it in month 11 and 12. If it was not renewed by the
> time the 12 months were up it should be deleted. If it was renewed
> prior to the 12 month anniversary it could either be set as valid for
> another 12 months from the date of renewal (prob better idea) or from
> the 12 month original date of registration.
I have changed the way Elist works as of v5.3 which has to undergo so more
code
changes but is set to allow 12 months between needing a update sent in, with
one Expiring warning followed by a Delete warning with another month before it
is actually deleted and the echo info transferred to the ELIST.NO database and
the report file ELSIT.NO where it is held for minimum 1 year.
Yes I can change that to 10 months again with one expiring warning and one
Deleting warning giving a total of 13 months before removal.
With the introduction of the extra code to support inclusion of the backbone
to
add to the database all echo's not under Moderator control to be included but
in this case only for producing a updated BACKBONE.NA file.
The same would apply after echo's have expired but instead of going to the .NO
database they would become BACKBONE echo's.
These BACKBONE entries by themselves would NOT have any entries for
Description
(Unless added by any one who know the content for a given echo area which can
be created by sending in a special file with just the description content
exactly the same way as sending in a .RUL file but named as :
GroupName.EchoName.DES (but all in upper case to help DOS sysops/users)
This allows the system to maintain a folder/directory containing description
by
Echo name within Group name (network name, i.e., FIDO, FSXNET etc) so that
they
can be used for the ELIST.RPT reports every three months where otherwsie this
file would only show the moderated echo's. This can be changed to using
another file name such as BACKBONE.RPT instead and leave the ELIST.RPT file
just for moderated areas.
This is all to be coded for and I am inclined to use the later Idea of
BACKBONE.RPT etc as it keep it clean.
Note the BACKBONE set of reports files would have ALL echo areas shown as they
is for sysops to use for their echo autoadd feature assuming their BBS does
that - mbse does but do not know what other can handle it.
Autoadd is where a new area come in and the system will set it the area up -
of course it would be up to downlinks to add themselves in :)
The coding now supports the Descriptions as a separate file with the database
being a lot smaller in size per record.
One area that I would like to do as well is, remove the storage for REPLY-TO
data as the elist software only records it but other does nothing with it
(other than for reports) as all Netmails goes out the the Moderator or if
expiring to all Co-Moderators on record.
The FROM keyword just help to keep the system reasonably secure to ensure only
the Mod or Co-mods can make changes along with knowing the password in use.
Hence the benefit of all areas having at least one Co-Mod in case the
Moderator
disappears for any reason.
The saving of storage space is around 100 Bytes (or characters per record
which
is now gone from 2,816 to 1,176 so would end up as 1076.
Does not look a lot but if there are say 500 echo areas recorded it make the
data part of the database 1076 x 500 = 538,000 but the indexes increase this a
lot say 3 - 5 M bytes -- writing this down it is not really a lot for the one
file :) but the other supporting files do increase it a tad along with the
back up and archived files as all submission files are retained as archives by
day and then by month within year on a JIC basis.
Helpful ?
Vincent
--- Mageia Linux v8 X64/Mbse v1.0.7.24/GoldED+/LNX 1.1.5-b20180707
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)
