• Echo time period and procedure for ELIST

    From Vincent Coen@2:250/1 to All on Thu Feb 3 17:57:31 2022
    Hello All!

    I am thinking of changing the life cycle of elist as well as warning messaging.

    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 :)


    What do you think ?

    It involves two changes to the program that will take me oh, 15 seconds.


    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)
  • From Paul Hayton@3:770/100 to Vincent Coen on Sun Feb 6 17:10:42 2022
    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.

    --- Mystic BBS v1.12 A47 2021/11/06 (Linux/64)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Vincent Coen@2:250/1 to Paul Hayton on Sat Feb 12 23:31:45 2022
    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)