Text 12325, 57 rader
Skriven 2022-01-14 18:23:42 av mark lewis (1:3634/12.73)
  Kommentar till text 12323 av Tim Schattkowsky (2:240/1120.29)
Ärende: Unix point?
===================
 On 2022 Jan 14 18:31:56, you wrote to me:

 ml>> FWIW: message bodies are unbounded in FTN specs... any limitations
 ml>> seen are placed there by the devs of those particular tools that
 ml>> exhibit message length problems...

 TS> I know,

i thought you probably did :)

 TS> but this clash with the reality of many implementations (not including
 TS> WP, at least up to ~2GB message length) makes the situation worse.
 TS> What I have seen is that commonly messages are in practice split at
 TS> slightly below 64k

this is what happens when hobbiests in highschool or early university write
things for use in a network like fidonet... i remember someone, years ago,
being quite happy and posting about them figuring out how to buffer the excess
to a disk file instead of trying to handle everything in memory with the 64k
limitation that was in effect back in those days... i think this was some time
after i had released a tool that was capable of posting the entire nodelist of
that time in one message... yeah... IIRC it was over 2G in size :)

 TS> and I am not sure if any real world software bothers recombining them
 TS> (WP does not).

perhaps you might look at the ^ASPLIT specification? there are tools that can
unsplit those messages, too... i've used one or two of them in the past...
generally they were used on the local side in the middle of the PKT processing
flow... they would process the incoming PKT and create a new PKT with the
messages put back together... then the tosser would run and place the full
message into the message base while also tossing to downstream system and again
splitting the message according to that system's tosser configs...

TBH, ^ASPLIT should have only been used on the local system if the message
could not fit in the local message base storage format... that would have been
a lot better than foisting it on all the systems in the path and making them
have more messages to process but that made too much sense, really...

 TS> However, since this was mostly relevanted for gated emails, it is
 TS> today probably of little practical interest anyway.

sadly, it wasn't limited to only gated messages... it was more of "lazy coders
unwilling or not knowing how to buffer to disk files"... this in the name of
processing speed and trying to get or have the fastest message processing
throughput they could attain... in today's world, they would still do
everything in memory without disk buffering but this is because the whole
methodology has changed and those former restrictions simply don't exist any
more...

)\/(ark

"The soul of a small kitten in the body of a mighty dragon. Look on my majesty,
ye mighty, and despair! Or bring me catnip. Your choice. Oooh, a shiny thing!"
... On T-Day that rash on your stomach turns out to be steering wheel burn.
---
 * Origin:  (1:3634/12.73)