Subj : Javascript weirdness
To   : deon
From : Digital Man
Date : Mon Apr 18 2022 10:18:49

  Re: Javascript weirdness
  By: deon to Digital Man on Mon Apr 18 2022 08:52 pm

 >   Re: Javascript weirdness
 >   By: Digital Man to deon on Sun Apr 17 2022 09:17 pm
 >
 >  >  > Yeah for me, its not happening on every msg area - on my laptop I only
 >  >  > have 4 or 5 with messages in (and a low number of messages), and it's
 >  >  > only happening to this one message base.
 >
 >  > Try using a simple script, like the one I pasted?
 >
 > Your script is not that different to mine, but I did try it anyway in case
 > it was the conditional handling. Still the same result :(.
 >
 > Perhaps I send you the msgbase and you see if you get the same result? It'll
 > have some messages tagged, and the 2 that wont.

Unless you use call the write() function? Yeah, please send me the message base.

 >  > Not without some padding to accomodate the extra data having been assured
 >  > to always be there. And then there would still be *some* limit
 >  > to how much additional data (e.g. the length of the tags header field
 >  > data) you could add. I could add an option to always pad headers for
 >  > specific message bases, if this is something you need. I'm not clear on
 >  > the use case. It was expected that a message author would add tags
 >  > to their message at the time of posting their message, if they wanted to.
 >  > Not after.
 >
 > So my use case is for my viewdata (videotex) shell that I've been chipping
 > away at the last year or so. With viewdata, everything is a "frame"
 > identified by a number - ie: *642# would display page 642 to the user. My
 > goal is that the content of frame 642 is a message in a mailbase.
 >
 > I'm also wanting to enable echomail messages to live on a static page, so
 > for example, *10010051234# would pull out message 1234 from the zone 0010
 > echomail area 05. Thus as a message is tossed, a post activity would tag the
 > next message in that echoarea as 1235, etc.
 >
 > I thought that keeping the frame numbers in the message base (via the tags
 > attribute) was workable, since that isnt really used at all anywhere else,
 > and I dont need to manage it outside the message base (and keep in sync with
 > it).
 >
 > I am only aiming to add 4 bytes (a 4 digit page number), so it would be
 > useful to pad the space to ensure that there is always room. I was going to
 > ask if it was too hard to "relocate" the message header, if there isnt room
 > in the current block to hold those extra 4 bytes, and the next block is
 > occupied (not sure if that is an option).

There's a *little* more overhead than just 4 bytes (for a 4-character tag), but not a ton. You're just close to the block-boundary with some of your existing message headers already, so unlucky.

It's not impossible to move headers upon change, but it's not something currently supported.

 > On a related question, if I set a message area to hold 10000 messages, and
 > the 10001 message comes it, message 1 is eligible for deletion - how is that
 > determined? By the lowest "number", the lowest "when_imported_time" (is
 > "when_imported_zone_offset" considered as well?) or some other field(s).

The order in the index (.sid file) which is generally the lowest number and the lowest when_imported_time first. The time's stored in UTC, so no, we don't need to worry about the time zone offset when sorting.
-- 
                                            digital man (rob)

Sling Blade quote #6:
Karl: he should've had a chance to grow up. He would had fun some time.
Norco, CA WX: 63.8øF, 66.0% humidity, 2 mph ESE wind, 0.00 inches rain/24hrs
--- SBBSecho 3.15-Linux
 * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

.