• DDMsgReader: When viewing message headers, now shows all available mes

    From Rob Swindell@VERT to GitLab note in main/sbbs on Tue Apr 25 20:56:19 2023
    https://gitlab.synchro.net/main/sbbs/-/merge_requests/288#note_3501

    Why wouldn't you use the symbolic constants defined in smbdefs.js rather than magic numbers here?

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Rob Swindell@VERT to GitLab note in main/sbbs on Tue Apr 25 21:00:17 2023
    https://gitlab.synchro.net/main/sbbs/-/merge_requests/288#note_3502

    Many of these header field types were never used and were just defined (aspirationally) 30 years ago. In fact, they're likely to be "undefined" (removed from smbdefs.h and smbdefs.js) in the future and potentially reused for some other purpose.

    For a reference of actually-used SMB header fields, see smb_fieldtype() in src/smblib/smbstr.c. Any header field type not listed there is not actually supported/used anywhere.

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Rob Swindell@VERT to GitLab note in main/sbbs on Tue Apr 25 21:02:51 2023
    https://gitlab.synchro.net/main/sbbs/-/merge_requests/288#note_3503

    What is the purpose of this (gSMBDefsLoaded)? It doesn't appear to be used anywhere.

    require() already does the necessary optimization. Checking for file existence seems unnecessary and a slight performance hit. Have you seen this example design pattern in any other exec/*.js files?

    Just move the `require("smbdefs.js", "SMB_POLL_ANSWER");` out of the condition and you'll be good to go.

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Eric Oulashin@VERT to GitLab note in main/sbbs on Tue Apr 25 21:54:40 2023
    https://gitlab.synchro.net/main/sbbs/-/merge_requests/288#note_3504

    Very few of these are defined in smbdefs, but I'll use the ones that are.

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Eric Oulashin@VERT to GitLab note in main/sbbs on Tue Apr 25 21:55:14 2023
    https://gitlab.synchro.net/main/sbbs/-/merge_requests/288#note_3505

    I looked through that list and removed the ones that I didn't see listed in there

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Rob Swindell@VERT to GitLab note in main/sbbs on Tue Apr 25 22:58:25 2023
    https://gitlab.synchro.net/main/sbbs/-/merge_requests/288#note_3510

    Right, but they're not defined for a reason: you'll never encounter them. A message header's field_list property will only ever contain the following header field types (from js_msgbase.c):
    ```
    case SMB_COMMENT:
    case SMB_POLL_ANSWER:
    case SMB_GROUP:
    case FIDOCTRL:
    case FIDOSEENBY:
    case FIDOPATH:
    case RFC822HEADER:
    case RFC822TO:
    case RFC822CC:
    case RFC822ORG:
    case RFC822FROM:
    case RFC822REPLYTO:
    case RFC822SUBJECT:
    case SMTPRECEIVED:
    case UNKNOWNASCII:
    ```
    So it seems like you're adding a whole bunch of code for no apparent reason. <shrug>

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Rob Swindell@VERT to GitLab note in main/sbbs on Tue Apr 25 23:09:24 2023
    https://gitlab.synchro.net/main/sbbs/-/merge_requests/288#note_3511

    Is there a reason you have both the "FTN_REPLY" and "X-FTN-REPLY" - are you actually seeing both of these in existence? I don't don't recall use dashes in property names, but I'm also not totally following this code either.

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Eric Oulashin@VERT to GitLab note in main/sbbs on Wed Apr 26 09:22:31 2023
    https://gitlab.synchro.net/main/sbbs/-/merge_requests/288#note_3512

    Naturally, I wouldn't want to add code for no reason. I had trimmed this down after your earlier comments, but I may have misunderstood a previous comment where you had mentioned looking at smb_fieldtype() in src/smblib/smbstr.c (those are probably not for field_list, I imagine?). I'll trim this down further to the ones you've mentioned above.

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Eric Oulashin@VERT to GitLab note in main/sbbs on Wed Apr 26 09:29:14 2023
    https://gitlab.synchro.net/main/sbbs/-/merge_requests/288#note_3513

    The following are not defined in smbdefs.js - Should these be?

    SMB_GROUP
    RFC822TO
    RFC822CC
    RFC822ORG
    RFC822FROM
    RFC822REPLYTO
    RFC822SUBJECT
    UNKNOWNASCII

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Eric Oulashin@VERT to GitLab note in main/sbbs on Wed Apr 26 09:37:27 2023
    https://gitlab.synchro.net/main/sbbs/-/merge_requests/288#note_3514

    I seem to remember seeing both of those in some messages years ago when I originally wrote this.

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Rob Swindell@VERT to GitLab note in main/sbbs on Wed Apr 26 10:48:39 2023
    https://gitlab.synchro.net/main/sbbs/-/merge_requests/288#note_3517

    Yeah, I'll add those to smbdefs.js. Haven't had a need/use-case before now. Some of these header fields (e.g. SMB_GROUP, UNKNOWNASCII) have never been used, so you'd never actually see one in a message.

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Rob Swindell@VERT to GitLab note in main/sbbs on Wed Apr 26 10:50:27 2023
    https://gitlab.synchro.net/main/sbbs/-/merge_requests/288#note_3518

    If propName in this context is an actual JS property name (of a msg header), then, you'll never see "X-FTN-*" - so that doesn't make sense to me.

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net