TZUTC: -0600   
   MSGID: 56836.sync_sys@1:103/705 2ba169d8   
   REPLY: 56831.sync_sys@1:103/705 2ba0e2f6   
   PID: Synchronet 3.20a-Linux master/6fc2a6b6f Nov 17 202 GCC 11.2.0   
   TID: SBBSecho 3.22-Linux master/1f37517ce Nov 17 2024 17:45 GCC 12.2.0   
   BBSID: PALANTIR   
   CHRS: CP437 2   
   -=> Ragnarok wrote to All <=-   
      
    Ra> El 17/11/24 a las 22:49, Gamgee escribi}|:   
      
    > I disagree.  I think this format is MUCH more awkward than the current   
    > format of AREAS.BBS.  If you have several hundred echo areas, and a   
    > couple dozen downlinks for most of them, the file would be *VERY* long   
    > and hard to edit.  EXTREMELY hard to edit, actually.   
      
    Ra> I understand your point, but using a more standard format makes it   
    Ra> easier to create tools that manage the file   
      
   We already have tools to manage it.  Text editors.   
      
    Ra> The length of the file due to the number of areas is not something that   
    Ra> worries me. If I have to edit it manually, any editor can do a text   
    Ra> search quickly, even if it has thousands of lines.   
      
   OK, so why would we need any additional tools?   
      
    > Also, that file is not specific to Synchronet only.   
    >   
    >   FT> this would make it easier to parse and you could even think of making   
    >   FT> an "Area manager" GUI with javascript and uifc or within sbbsecho   
    >   
    >   FT> or from the command line it could also have utilities like:   
    >   
    >   FT> jsexec areamgr.js addarea [internal_code] [fido_tag] [link] [link]   
    >   FT> jsexec areamgr.js addlink [fido_tag] [link]   
    >   FT> jsexec areamgr.js dellink [fido_tag] [link]   
    >   
    > This can already be done with the Import/Export functions already in   
    > SCFG.   
    >   
      
    Ra> The import/export actions to different formats are not for managing the   
    Ra> file.   
      
   Sure they are.  For example, you add a whole new FTN network, and then    
   you can simply export it to update (add to) the existing AREAS.BBS.   
      
    Ra> I don't see a way to simple make those use cases as this:   
      
    Ra> "add node 1:23/4 to areas X,Y and Z"   
    Ra> "remove node 1:23/4 from area X"   
      
   That's true, the import/export isn't for that.  But, see above regarding    
   text editors.  Very simple thing to do.   
      
    Ra> The ini format was just an example, maybe it could be a comma or tab   
    Ra> separated file like user.tab is now   
      
    Ra> I currently use sed, awk or other bash tools to do these tasks. But the   
    Ra> inconsistencies of the lines (some have different spaces between the   
    Ra> columns) makes it uncomfortable.   
      
   While those tools are useful, they're probably more trouble than they're    
   worth for something like this.  You can easily edit the file with your    
   preferred text editor, and while you're in there, fix the spacing/tabs    
   to make it look the way you want it to.  Not difficult.   
      
   My whole point is that the existing format is very simple and efficient,    
   and is EASY to edit.  Why complicate it just to "justify" the creation    
   of more "tools" we could use?  We already have the tools.   
      
      
      
   ... Gone crazy, be back later, please leave message.   
   --- MultiMail/Linux v0.52   
    þ Synchronet þ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL   
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)   
   SEEN-BY: 10/0 1 102/401 103/1 17 705 105/81 106/201 124/5016 128/187   
   SEEN-BY: 153/7715 214/22 218/0 1 215 601 700 720 840 860 870 880 930   
   SEEN-BY: 226/30 227/114 229/110 114 206 317 400 426 427 428 470 550   
   SEEN-BY: 229/700 705 266/512 280/464 282/1038 291/111 301/1 320/219   
   SEEN-BY: 322/757 342/200 396/45 460/58 633/280 712/848 5075/35   
   PATH: 103/705 218/700 229/426