REPLY: 3:770/100 86f5cc21   
   MSGID: 2:250/1@fidonet 62084362   
   CHRS: UTF-8 2   
   TZUTC: 0000   
   TID: MBSE-FIDO 1.0.7.24 (GNU/Linux-x86_64)   
   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)   
   SEEN-BY: 1/123 15/0 25/0 21 30/0 90/1 103/705 105/81 106/201 120/340   
   SEEN-BY: 123/131 129/305 330 331 153/7715 154/10 218/700 221/1 6 226/30   
   SEEN-BY: 227/114 229/110 200 206 317 400 424 426 428 664 700 240/1120   
   SEEN-BY: 240/5832 250/0 1 2 3 4 5 6 7 8 10 11 21 263/0 266/512 275/1000   
   SEEN-BY: 280/464 282/464 1038 292/854 301/0 1 101 113 123 812 317/3   
   SEEN-BY: 320/219 322/757 342/200 396/45 460/58 633/280 640/1321 712/848   
   SEEN-BY: 920/1 3634/12 5058/104   
   PATH: 250/1 301/1 229/426