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...
Change 6 months to 12, Change four warning and a delete warning
to one warning and the delete warning so this will give a total
of 15 months from last update submission before removal as
against 11-12 months.
Gives a little more time to assess if the feed is broken or the
Echo has left the farm - no longer fit for purpose etc, pick your
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)