Hi DM,
Today, while using my custom JS message reader, I noticed that one of my message sub-boards appears to be skipping an offset. For example, message number 3405 (offset 3404) doesn't seem to exist.
My message reader sees
messages 3404 and 3406 as valid messages, but there's nothing at message number 3405 (which would be offset 3404).
When I use the built-in reader,
it skips that message but the numbers are sequential - According to the built-in reader, message number 3405 seems to be what my reader thinks is 3406.
In the JavaScript interface, I had thought that message offsets would
all be valid between 0 and the number of messages in the messagebase. Is that not the case?
In the JavaScript interface, is it necessary to go
through all message offsets to make sure a valid message can be retrieved?
Today, while using my custom JS message reader, I noticed that one of my message sub-boards appears to be skipping an offset. For example, message number 3405 (offset 3404) doesn't seem to exist. My message reader sees messages 3404 and 3406 as valid messages, but there's nothing at message number 3405 (which would be offset 3404). When I use the built-in reader,
My message reader sees
messages 3404 and 3406 as valid messages, but there's nothing at
message number 3405 (which would be offset 3404).
By default, the JS MsgBase does not return votes as messages (e.g. using get_all_msg_headers).
In the JavaScript interface, I had thought that message offsets would
all be valid between 0 and the number of messages in the messagebase.
Is that not the case?
It is the case. But you probably don't want to load votes, so the default "include_votes" parameter value (to get_msg_index, get_msg_header and get_all_msg_headers) is false.
In the JavaScript interface, is it necessary to go
through all message offsets to make sure a valid message can be
retrieved?
I'm not really sure what you're asking. If you pass "true" as the last
argument to those get_* methods I mentioned, you'll get votes too, but then you'll have to filter those manually (you don't need/want to try to display vote to the user). So I think current behavior is what you will want, but you'll need to be able to handle the case get_msg_index might return null (just move to the next offset value).
Today, while using my custom JS message reader, I noticed that one
of my message sub-boards appears to be skipping an offset. For
example, message number 3405 (offset 3404) doesn't seem to exist. My
message reader sees messages 3404 and 3406 as valid messages, but
there's nothing at message number 3405 (which would be offset 3404).
When I use the built-in reader,
Nothing as in "no message header" (you try to read the header and get 'null') or nothing as in "no message body" (null), or both?
I'm wondering if this is related to the new 'vote messages'. They coexist with the rest of the messages in a sub, but have no message body, have a special attribute in the header, have no subject line, and are probably different in a couple of other ways.
Today, while using my custom JS message reader, I noticed that one
of my message sub-boards appears to be skipping an offset. For
example, message number 3405 (offset 3404) doesn't seem to exist. My
message reader sees messages 3404 and 3406 as valid messages, but
there's nothing at message number 3405 (which would be offset 3404).
When I use the built-in reader,
Nothing as in "no message header" (you try to read the header and get 'null') or nothing as in "no message body" (null), or both?
Re: Messagebase skipping a number
By: echicken to Nightfox on Sat Nov 19 2016 23:15:05
Today, while using my custom JS message reader, I noticed that one
of my message sub-boards appears to be skipping an offset. For
example, message number 3405 (offset 3404) doesn't seem to exist. My
message reader sees messages 3404 and 3406 as valid messages, but
there's nothing at message number 3405 (which would be offset 3404).
When I use the built-in reader,
Nothing as in "no message header" (you try to read the header and get 'null') or nothing as in "no message body" (null), or both?
It looks like the message header is null.
It looks like the message header is null.
Doesn't your reader already filter out some messages based on attributes (deleted messages, unvalidated messages, private mesages)? You could just add the new VOTE and POLL attributes to your checking/filtering logic.
The main advantages of using the get_all_msg_headers() method is speed (that's why it was created) and it now tallies the votes for you and puts the results in the message headers (currently, just upvotes and downvotes). The main disadvantage is that it didn't exist before sbbs v3.16.
It looks like the message header is null.
I usually check for this every time I load a message header from a MsgBase, and skip the message if the header === null. It crops up once in a while for various reasons (though I don't generally bother with the by_offset thing, maybe it's less of an issue in that case) so I've just adopted it as a normal practice.
Re: Messagebase skipping a number
By: Digital Man to Nightfox on Sat Nov 19 2016 22:58:18
Doesn't your reader already filter out some messages based on attributes (deleted messages, unvalidated messages, private mesages)? You could just add the new VOTE and POLL attributes to your checking/filtering logic.
It doesn't yet, but that's something that has been on my mind to add.
I could do a version check to make sure my reader only calls get_all_msg_headers() on 3.16 and above. At first I was thinking of requiring 3.16 or higher, but I'd like it to be backwards-compatible.
It doesn't yet, but that's something that has been on my mind to add.
So if you or a user deletes a message, it remains visible to everyone? For the built-in reader, that behavior is configurable (SCFG->Message Options->User Can View Deleted Messages), the default setting is "Sysops Only", I think.
Simplest/safest might be:
if (typeof msgbase.get_all_msg_headers === 'function') {}
Saves you from having to worry about which version/release that method first appeared in.
| Sysop: | fluid |
|---|---|
| Location: | wickliffe, ohio |
| Users: | 5 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 203:18:00 |
| Calls: | 50 |
| Files: | 15,838 |
| Messages: | 50,771 |