I was looking at the header information provided for some of my FidoNet messages, via JavaScript, and it seems there are some pieces of information that are not provided - For example, seen-by, via path, CHRS (character set?), and codepage. I've heard from other sysops that GoldEd+ shows that information for the messages.. Would Synchronet be able to provide those fields in the message headers in JavaScript?
I was looking at the header information provided for some of my
FidoNet messages, via JavaScript, and it seems there are some pieces
of information that are not provided - For example, seen-by, via
path, CHRS (character set?), and codepage. I've heard from other
sysops that GoldEd+ shows that information for the messages.. Would
Synchronet be able to provide those fields in the message headers in
JavaScript?
For the record, as is your message reader, Golded's kludge lines are toggleable. Where Slyedit you're able to press "K" or "H" or whatever, Golded is ALT-V. The only difference is that Golded displays them right in the message as they were when the message arrived (and removes them with another ALT-V), rather than Slyedit displaying a separate page of only the kludges.
Hi DM,
I was looking at the header information provided for some of my FidoNet messages, via JavaScript, and it seems there are some pieces of information that are not provided - For example, seen-by, via path, CHRS (character set?), and codepage. I've heard from other sysops that GoldEd+ shows that information for the messages.. Would Synchronet be able to provide those fields in the message headers in JavaScript?
SlyEdit does not display kludge lines - That's my message reader that does that.
I was curious about this because there seem to be a few kludge line information fields that Synchronet doesn't seem to make available in JavaScript (but seem to be accessible by GoldEd+).
If the tosser is configured to not strip kludge lines, then they should be in the message headers already. You can use the (O)perator, (H)eaders command with the internal message reading interface or smbutil to view the header fields. Most of them a not really intended for display to users/readers.
If the tosser is configured to not strip kludge lines, then they should be in the message headers already.
You can use the (O)perator, (H)eaders
command with the internal message reading interface or smbutil to view the header fields. Most of them a not really intended for display to users/readers.
If the tosser is configured to not strip kludge lines, then they should be in the message headers already. You can use the (O)perator, (H)eaders command with the internal message reading interface or smbutil to view the header fields. Most of them a not really intended for display to users/readers.
SlyEdit does not display kludge lines - That's my message reader
that does that.
LOL. I think you've witnessed that is not the first time I've mixed up the two names. :)
Using the two together (DDMR and Slyedit) is basically like using one all-in-one package like Golded (but within the BBS). Probably why I keep calling one the other and vise versa.
If the tosser is configured to not strip kludge lines, then they
should be in the message headers already. You can use the
(O)perator, (H)eaders command with the internal message reading
interface or smbutil to view the header fields. Most of them a not
really intended for display to users/readers.
While that's definitely an option. I think Nightfox is looking for a way to be able to incorporate viewing them in his message reader. There's already an option while reading to hit a key and view the header information and kludges (for some that actually like to debug things). At the moment I don't think he's able to pull things like TZUTC, SEEN-BY, PATH, and possibly a few others.
If the tosser is configured to not strip kludge lines, then they
should be in the message headers already. You can use the
(O)perator, (H)eaders command with the internal message reading
interface or smbutil to view the header fields. Most of them a not
really intended for display to users/readers.
Also, if that information is viewable from the internal reader, I think it would be useful if all the same information was available in JavaScript.
If the tosser is configured to not strip kludge lines, then they should be in the message headers already. You can use the (O)perator, (H)eaders command with the internal message reading interface or smbutil to view the header fields. Most of them a not really intended for display to users/readers.
While that's definitely an option. I think Nightfox is looking for a way to be able to incorporate viewing them in his message reader. There's already an option while reading to hit a key and view the header information and kludges (for some that actually like to debug things). At the moment I don't think he's able to pull things like TZUTC, SEEN-BY, PATH, and possibly a few others.
Re: Network messsage information missing
By: Digital Man to Nightfox on Sun Oct 18 2015 00:03:18
If the tosser is configured to not strip kludge lines, then they should be in the message headers already.
I had a look at the headers for one of my FidoNet messages, and although it had some kludge line information such as the message ID, PID, etc., it didn't have seen-by, via, characters, or codepage (which I've heard GoldEd+ will display).
You can use the (O)perator, (H)eaders
command with the internal message reading interface or smbutil to view the header fields. Most of them a not really intended for display to users/readers.
I understand - But it seems that a sysop might be interested in seeing such information. My reader only allows the sysop to view that information, similar to Synchronet's built-in reader.
Re: Network messsage information missing
By: Digital Man to Nightfox on Sun Oct 18 2015 00:03:18
If the tosser is configured to not strip kludge lines, then they should be in the message headers already. You can use the (O)perator, (H)eaders command with the internal message reading interface or smbutil to view the header fields. Most of them a not really intended for display to users/readers.
Also, if that information is viewable from the internal reader, I think it would be useful if all the same information was available in JavaScript.
Re: Network messsage information missing
By: Nightfox to Digital Man on Sun Oct 18 2015 08:40:49
If the tosser is configured to not strip kludge lines, then they
should be in the message headers already. You can use the
(O)perator, (H)eaders command with the internal message reading
interface or smbutil to view the header fields. Most of them a not
really intended for display to users/readers.
Also, if that information is viewable from the internal reader, I think it would be useful if all the same information was available in JavaScript.
I think I had some options set up in echocfg that may have been removing some of the kludge lines, which might be why I wasn't seeing all of them. I had "Store PATH Lines in Message Base", "Store SEEN-BY Lines in Message Base", and "Store Unknown Kludge LInes in Message Base" set to "No", and I had "Zone Blind SEEN-BY and PATH Lines" set to Disabled. I'll enable those options and see if I will start getting more kludge lines in my message headers.
I had a look at the headers for one of my FidoNet messages, and
although it had some kludge line information such as the message ID,
PID, etc., it didn't have seen-by, via, characters, or codepage (which
I've heard GoldEd+ will display).
Looked at the headers how? The only kludge lines that SBBSecho will (optionally) strip are the PATH and SEEN-BYs. If the others aren't in the SMB headers, then they most likely just weren't in the originally imported FTN message. Not every message has every possible kludge in it.
Re: Network messsage information missing
By: Digital Man to Nightfox on Sun Oct 18 2015 23:49:58
I had a look at the headers for one of my FidoNet messages, and
although it had some kludge line information such as the message ID,
PID, etc., it didn't have seen-by, via, characters, or codepage (which
I've heard GoldEd+ will display).
Looked at the headers how? The only kludge lines that SBBSecho will (optionally) strip are the PATH and SEEN-BYs. If the others aren't in the SMB headers, then they most likely just weren't in the originally imported FTN message. Not every message has every possible kludge in it.
I had a look at the headers in JavaScript. For instance, if I have a message header object called msgHdr, I did this:
for (var property in msgHdr)
console.print(property + ": " + msgHdr[property] + "\r\n"); console.pause();
I think GoldEd+ looks nice, but I was disappointed when I found that it doesn't seem to handle Synchronet's message group prefixes (and thus, it got confused with a lot of my message areas). I suppose there might be a way around that though - I suppose I'd just have to look/ask around.
I think GoldEd+ looks nice, but I was disappointed when I found that
it doesn't seem to handle Synchronet's message group prefixes (and
thus, it got confused with a lot of my message areas). I suppose
there might be a way around that though - I suppose I'd just have to
look/ask around.
It does handle SMB, it's just not documented. I think you have to point the configuration to the msgs.cnf file or something in those lines. That and if you pack/renumber your message bases, Golded loses track of the last read pointers and considers every message in the area as new again.
In other words, you'd have to tinker with Synchronet a bit to make it work perfectly. You also can't actually use it from the BBS, so there's that too.
I thought we resolved the reason you weren't seeing the header fields you were looking for (they were being stripped by SBBSecho per your configuration settings). Is this still an open question?
I think GoldEd+ looks nice, but I was disappointed when I found that
it doesn't seem to handle Synchronet's message group prefixes (and
thus, it got confused with a lot of my message areas). I suppose
there might be a way around that though - I suppose I'd just have to
look/ask around.
It does handle SMB, it's just not documented. I think you have to point the configuration to the msgs.cnf file or something in those lines. That and if you pack/renumber your message bases, Golded loses track of the last read pointers and considers every message in the area as new again.
In other words, you'd have to tinker with Synchronet a bit to make it work perfectly. You also can't actually use it from the BBS, so there's that too.
So, definitely can't recommend letting it try to do the automated method of the msgs.cnf, as that screws a lot of things up. :)
Yeah, I did all that, and I did get it to work with Synchronet, to an extent.. I found that I had to remove the internal code prefixes in SCFG order to get GoldEd+ to understand my message bases. For instance, in SCFG, I have Synchronet set up to prefix my Dove-Net internal codes with "DOVE_", so the "General" area, which normally has an internal code of DOVE-GEN, becomes DOVE_DOVE-GEN. GoldEd+ didn't deal with that very well - GoldEd+ would see that the "General" area should have an internal code of "DOVE-GEN", and it wasn't reading it correctly because it's actually "DOVE_DOVE-GEN" on my system.
When I posted about this last time (several months ago), I remember someone saying Synchronet added the internal code prefixes after GoldEd+ implemented its Synchronet support, so it sounded like GoldEd+ simply has limited Synchronet support. I'm not sure if there's a good way around the issue without GoldEd+ being updated.
instance, in SCFG, I have Synchronet set up to prefix my Dove-Net
internal codes with "DOVE_", so the "General" area, which normally
has an internal code of DOVE-GEN, becomes DOVE_DOVE-GEN. GoldEd+
didn't deal with that very well - GoldEd+ would see that the
"General" area should have an internal code of "DOVE-GEN", and it
wasn't reading it correctly because it's actually "DOVE_DOVE-GEN" on
my system.
Ah yes. I remember that one too, now. Then again, how and/or why would Golded+ understand something that Synchronet does internally (prefixes are only something for Synchronet itself. When messages in those echos get exported to other systems, the prefix is dropped off of them, I believe).
Either that, or the whole prefix things gets broken when msgs.cnf is read, which also wouldn't be a Golded+ problem, would it?
When I posted about this last time (several months ago), I remember
someone saying Synchronet added the internal code prefixes after
GoldEd+ implemented its Synchronet support, so it sounded like
GoldEd+ simply has limited Synchronet support. I'm not sure if
there's a good way around the issue without GoldEd+ being updated.
Or it's possible msgs.cnf isn't giving that information to Golded+?
I'm not sure if we ever got an answer on any of that (or if we actually asked someone that would know). If we did, I don't remember. :)
Re: Network messsage information missing
By: Digital Man to Nightfox on Mon Oct 19 2015 16:15:04
I thought we resolved the reason you weren't seeing the header fields you were looking for (they were being stripped by SBBSecho per your configuration settings). Is this still an open question?
Well, it seems that when I iterate through the header fields in JavaScript, I'm not seeing all the same information that Synchronet's built-in reader shows when I have it display the header information. But I suppose I'll have to investigate more to be sure.
So, definitely can't recommend letting it try to do the automated
method of the msgs.cnf, as that screws a lot of things up. :)
Oddly enough, the last time I tried it I had much more successful results, besides the fact that I packed/renumbered my message areas with Synchronet, only to find 5000 new messages in just about every message base. *shrug*
Either way, I have had it working just fine using that method.. so I don't know what happened in your case that screwed a lot of things up.
I had a look at the headers in JavaScript. For instance, if I have a message header object called msgHdr, I did this:
for (var property in msgHdr)
console.print(property + ": " + msgHdr[property] + "\r\n");
---
echicken
Just curious, is there something wrong with the editor you are using? It
just---
echicken
Just curious, is there something wrong with the editor you are using? It seems your starting line is any number of spaces in for each paragraph,
curious if that is intentional?
I've also noticed odd formatting issues with your messages while using the older (Runemaster?) web interface - It's like your text is right-justified. However it looks okay when reading in the telnet terminal.
I had a look at the headers in JavaScript. For instance, if I have a
message header object called msgHdr, I did this: for (var property in
msgHdr) console.print(property + ": " + msgHdr[property] + "\r\n");
You might try 'console.print(JSON.stringify(msgHdr));' to get a bit more depth. The header has a 'field_list' property which (the docs suggest anyway) is an array of objects each with '.type' and '.data' properties. Iterating over top-level properties would miss this (or just show [Object object] or somesuch as the value for this property.)
Of course, I don't know what you'll find in that array, but it might be a place where any unaccounted-for header fields get stuffed into.
Well, it seems that when I iterate through the header fields in
JavaScript, I'm not seeing all the same information that Synchronet's
built-in reader shows when I have it display the header information.
But I suppose I'll have to investigate more to be sure.
All of the header fields should be available via JS. If you have an example of the discrepencies, please share. It's always possible that there is a bug somewhere, but we've had other JS-methods of displaying the header fields (event the old runemaster/WebUI has that ability) and scripts which convert them (e.g. to NNTP equivalents) and I've never noticed a problem with it. If you do continue to see a problem, please let me know. Thanks,
Subject: Network messsage information missing
@MSGID: <562C2726.2022.dove_sync_js@digitaldistortionbbs.com>
@REPLY: <5627549B.2032.sync-js@vert.synchro.net>
@TZ: c1e0
Re: Network messsage information missing
By: Digital Man to Nightfox on Wed Oct 21 2015 02:02:19
Well, it seems that when I iterate through the header fields in
JavaScript, I'm not seeing all the same information that Synchronet's
built-in reader shows when I have it display the header information.
But I suppose I'll have to investigate more to be sure.
All of the header fields should be available via JS. If you have an example of the discrepencies, please share. It's always possible that there is a bug somewhere, but we've had other JS-methods of displaying the header fields (event the old runemaster/WebUI has that ability) and scripts which convert them (e.g. to NNTP equivalents) and I've never noticed a problem with it. If you do continue to see a problem, please let me know. Thanks,
I've looked into it a bit more, and I think I understand it a bit better.
It looks like the field_list array in the header is meant to contain other arbitrary message header data. It looks like the 'type' property of each object in field_list is a number, and the .data property is the information for that field. Is there any documentation that lists the field types in the field_list and the numbers that they correspond to?
It looks like 162
is FTN seen-by and 163 is FTN path, but I've also seen 176 for some messages, and I'm not sure what that represents, or what other types might exist.
better. It looks like the field_list array in the header is meant to
contain other arbitrary message header data. It looks like the 'type'
property of each object in field_list is a number, and the .data
property is the information for that field. Is there any
documentation that lists the field types in the field_list and the
numbers that they correspond to?
Yes, here: http://synchro.net/docs/smb.html#Header Field Types:
But note that the values are given in hexadecimal.
| Sysop: | Ree |
|---|---|
| Location: | Toronto, ON |
| Users: | 2 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 115:41:39 |
| Calls: | 375 |
| Calls today: | 2 |
| Files: | 2 |
| Messages: | 38,886 |