Hi,

any idea what the charset below is supposed to mean? Pure garbage?

Regards,
Tim

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-<
This message has been _forwarded_! The original message was: <
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-<
Area: *POINTS*
From: *Adam Wysocki(2:480/138)*
To: *Andy Ball*
Subject: *Unix point?*
Sent: *27.01.07* *22:36:34*
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-<

@REA:POINTS
@MSGID: 2:480/138@FidoNet 45bbc62c

@CHRS: FIDOMAZ 2

Hej Andy!

27 Dec 06 22:37, you wrote to All:

How difficult is it to set up a point on a system that runs NetBSD or Linux? I have a DSL connection to the Internet, but could probably arrange dial-up access if that's preferable. I'm in zone 1, region
11, so I should probably find a boss node that's somewhere in r11.

Hi Andy,

I've done it using binkd, crashmail and golded+ under Linux. It's certainly possible, just get the software.

Regards,
g.

-+- GoldED+/LNX 1.1.4.7
@ Origin: http://www.chmurka.net/ (2:480/138)
SEEN!BY:24/905 240/2188 5138 5778 246/2027 249/3110 313/41 423/81 774/605 SEEN!BY:2411/413 2432/0 200 201 215 300 2433/401 2437/40 209 2443/1311
@PATH: 480/138 127 280/1027 261/38 123/500 774/605 2432/200 2437/40 >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-<

End of forwarded message <
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-<

Regards,
Tim
--- WinPoint 389.0
* Origin: Original WinPoint Origin! (2:240/1120.29)

Hi Tim,

On 2022-01-10 18:12:59, you wrote to All:

any idea what the charset below is supposed to mean? Pure garbage?

Adam Wysocki is still in the nodelist, with that nodenumber, although on Hold for the last 4,5 years, so he has probably left fidonet.

If you haven't seen it used more recently then 2007 in below message, I wouldn't worry about it! ;-)

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=-=
-< This message has been _forwarded_! The original message was:
<
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-<
Area: *POINTS*
From: *Adam Wysocki(2:480/138)*
To: *Andy Ball*
Subject: *Unix point?*
Sent: *27.01.07* *22:36:34*
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-<

@REA:POINTS
@MSGID: 2:480/138@FidoNet 45bbc62c

@CHRS: FIDOMAZ 2

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hey Andy!

How difficult is it to set up a point on a system that runs NetBSD or Linux?

A piece of cake. All I use is bash and have been for points since about 2002-ish or so. Before that I more of less followed the Husky Project strategy which is overkill for a point ... or even a bossnode for that matter.

Life is good,
Maurice

... Gewurdene wyrda, ðæt beoð ða feowere fæges rapas.
Things which have happened: those are the four ropes of the doomed.
--- GNU bash, version 5.1.8(1)-release (x86_64-moosile-linux-gnu)
* Origin: One of us @ (1:153/7001.2989)

//Hello Maurice,//

on *10.01.22* at *10:39:30* You wrote in rea *FTSC_PUBLIC*
to *Andy Ball* about *"Unix point?"*.

@ENCODING: UTF-8

Whats that?

Regards,
Tim
--- WinPoint 389.0
* Origin: Original WinPoint Origin! (2:240/1120.29)

Hey Tim!

@ENCODING: UTF-8

Whats that?

On this point it corresponds to the 1179 IANA endorsed encodings and proper aliases. I wanted something more powerful at my disposal in order to support CP866 and the like. However I haven't done much of that but I do know it works. Also I've run across a few people in my fidonet msg-ing travels in the past who would have appreciated this type of support.

Life is good,
Maurice

... Ða ne sacað þe ætsamne ne beoð.
They do not quarrel who are not together.
--- GNU bash, version 5.1.8(1)-release (x86_64-moosile-linux-gnu)
* Origin: One of us @ (1:153/7001.2989)

Maurice wrote (2022-01-10):

Hey Tim!

@ENCODING: UTF-8

Whats that?

On this point it corresponds to the 1179 IANA endorsed encodings and proper aliases. I wanted something more powerful at my disposal in order to support CP866 and the like.

Really?

What's next? base64, 8bit? Full MIME support?

Thank God the CHRS kludge never made it to a standard and nobody uses it ....

🖀 🕹️

---
* Origin: Birds aren't real (2:280/464.47)

Hey Oli!

"CHRS: UTF-8 2"

Thank God the CHRS kludge never made it to a standard and nobody
uses it ....

Are you being sarcastic? Also you're getting it wrong just like every other DOS-think braindead editor.

🖀 🕹️

U+1F580 = joystick
U+1F579 = telephone over modem

I am guessing it is meant to symbolize online gaming.

Life is good,
Maurice

... Wel bið þam eorle þe him on innan hafað... rume heortan.
Well shall it be for the man who has within him a generous heart.
--- GNU bash, version 5.1.8(1)-release (x86_64-moosile-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

//Hello Maurice,//

on *12.01.22* at *13:05:30* You wrote in rea *FTSC_PUBLIC*
to *Oli* about *"Unix point?"*.

Hey Oli!

"CHRS: UTF-8 2"

Thank God the CHRS kludge never made it to a standard and nobody uses it
....

Are you being sarcastic? Also you're getting it wrong just like every other DOS-think braindead editor.

I think this is a small hint, that everything already works fine using the existing Kludge. There is no advantage in your proposal ;)

如果它没有坏，不要修理它

🖀 🕹️

U+1F580 = joystick
U+1F579 = telephone over modem

I am guessing it is meant to symbolize online gaming.

Life is good,
Maurice

... Wel bið þam eorle þe him on innan hafað... rume heortan.
Well shall it be for the man who has within him a generous heart.
--- GNU bash, version 5.1.8(1)-release (x86_64-moosile-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Regards,
Tim
--- WinPoint 389.0
* Origin: Original WinPoint Origin! (2:240/1120.29)

Hey Tim!

There is no advantage in your proposal

What proposal?

Life is good,
Maurice

... Seldan snottor guma sorgleas blissað.
Seldom does a wise man rejoice without sorrow.
--- GNU bash, version 5.1.8(1)-release (x86_64-moosile-linux-gnu)
* Origin: One of us @ (1:153/7001.2989)

//Hello Maurice,//

on *13.01.22* at *2:21:07* You wrote in rea *FTSC_PUBLIC*
to *Tim Schattkowsky* about *"Unix point?"*.

Hey Tim!

There is no advantage in your proposal

What proposal?

All those redundant Kludges you use instead of the standard ones that cause your messages to shop up in the wrong place in my message list (no TZ info) and render with some garbage (no CHRS).

Regards,
Tim
--- WinPoint 389.0
* Origin: Original WinPoint Origin! (2:240/1120.29)

Hey Tim!

All those redundant Kludges you use instead of the standard ones

Ah! Here is a reply with none of that. I seriously doubt that is the problem though and if it is then you will discover many msgs that don't follow those particuar standards. As far as I know they aren't required. Do you know better?

I think you got suckered in.

Life is good,
Maurice

... Don't cry for me I have vi.
--- GNU bash, version 5.1.8(1)-release (x86_64-moosile-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

On 2022 Jan 13 17:05:36, you wrote to Maurice Kinal:

There is no advantage in your proposal

What proposal?

All those redundant Kludges you use instead of the standard ones that cause
your messages to shop up in the wrong place in my message list (no TZ info)
and render with some garbage (no CHRS).

his point is that he did not make a proposal (yet)...

granted, he could/should use the existing control lines in addition to the one's he testing and may eventually propose...

)\/(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!"
... an Australian kiss is basically a French kiss, BUT DOWN UNDER
---
* Origin: (1:3634/12.73)

Hey mark!

he could/should use the existing control lines in addition to
the one's he testing

Do you mean like this reply?

and may eventually propose...

I doubt I'll live that long.

Anyhow I've already tested this particular idea and ended up rejecting it. However in the spirit of demonstration, I'll try one more time although it doesn't look any better than the last test. I maintain the CHRS and TZUTC should both be turfed never to be mentioned ever again for all eternity. Also the two digit year in the msgHeader while we're at it but that is another can of worms that *could* have been fixed with a proper utc offset and not the emasculated fts-4008.002 version.

Life is good,
Maurice

... Ælces monnes lif bið sumes monnes lar.
Every man's life may be a lesson to someone.
--- GNU bash, version 5.1.8(1)-release (x86_64-moosile-linux-gnu)
* Origin: One of us @ (1:153/7001.2989)

On 2022 Jan 13 13:48:36, you wrote to me:

@REPLY: 1:3634/12.73 61e08216
@MSGID: 1:153/7001.2989 61e0a1bb
@ENCODING: UTF-8
@CHRS: UTF-8 4
@TZ: UTC+08:15:02
@TZUTC: -0815
Hey mark!

he could/should use the existing control lines in addition to
the one's he testing

Do you mean like this reply?

yes... but i have to wonder about the TZ control line having seconds in it... i'm also not so sure that UTC+8 hours is right for a system located on the western coast of Canada... unless your TZ code is using a/the non-POSIX format(?) or you are playing with your clock time as well ;)

and may eventually propose...

I doubt I'll live that long.

it doesn't take long to come up with an idea that is good which other developers pick up and put into use... once that's done, the idea is all fleshed out, and working properly, one then only needs to write the proposal with the details of the idea and it's implementation and present said proposal for other developers to also pick up and start using if they want to...

Anyhow I've already tested this particular idea and ended up rejecting
it.

why?

However in the spirit of demonstration, I'll try one more time
although it doesn't look any better than the last test. I maintain
the CHRS and TZUTC should both be turfed never to be mentioned ever
again for all eternity.

TZUTC is in place to clarify the time stamp in the message header since it is local time with no other indication of where "local" is...

have you looked at any of the other PKT and packed message formats? have you implemented any of them and gotten other developers to also implement them? that's what it takes to get things changed, ya know...

Also the two digit year in the msgHeader while we're at it but that is another can of worms that *could* have been fixed with a proper utc
offset

this is true but we also have to remember how storage was back in the days when these formats were created... i remember being logged into a few BBSes and having to ask the operator to change floppies in some drive so i could read older or newer messages or even to access some files that were offline at that time... generally speaking, after a few minutes, they would tell me to try again and there they were... that being because they had switched the data floppy out for the desired one... ahhh, the olden days when operators had to actually operate their systems :)

and not the emasculated fts-4008.002 version.

i still cannot believe all this knicker twisting because somehow one cannot or refuses to code for a space or lack of a negative symbol to be recognized as a positive indicator before a number... i mean, that is the defacto standard all over the world where numbers are used... imagine if our math had to be written like this

+2 + +2 = +4

instead of the much more common

2 + 2 = 4

really?? [smh]

)\/(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!"
... We can't have a crisis today, my schedule is already full.
---
* Origin: (1:3634/12.73)

Hey mark!

i have to wonder about the TZ control line having seconds in it

It is based on a system that is still on the books but fell out of use back in 1916. It definetly allows for seconds as well as deploying the '+' character for west of prime meridian and '-' for east opposite of the TZUTC kludge.

TZUTC is in place to clarify the time stamp in the message
header since it is local time with no other indication of where
"local" is...

Understood. Without the '+' character it becomes a meaningless string. Effectively it has been castrated.

have you looked at any of the other PKT and packed message
formats?

Type 2, 2+ and 2.2. 2.2 only works with one of my uplinks. However this has nothing to do with utc offsets which are part of the msg body.

+2 + +2 = +4

Fine for numbers but lousy for strings.

TZUTC1 + TZUTC2 = ?!?!?!?!?!?!

What in the name of strftime() is confusing you? You appear to be suffering from the same affliction as everyone east of prime meridian (castration?). +0000 is a string (N)ot (a) (N)umber (<- NaN). Stripping off the '+' character effectively corrupts it.

really??

Yes. Basic programming skills inform me that strings are not numbers even if they look like numbers. The utc offset *is* a string ... or at least real life ones are.

Life is good,
Maurice

... Gemyne mærþo, mægenellen cyð, waca wið wraþum.
Think of glory, show great courage, keep watch against the foe.
--- GNU bash, version 5.1.8(1)-release (x86_64-moosile-linux-gnu)
* Origin: One of us @ (1:153/7001.2989)

//Hello mark,//

on *14.01.22* at *12:00:38* You wrote in rea *FTSC_PUBLIC*
to *Maurice Kinal* about *"Unix point?"*.

have you looked at any of the other PKT and packed message formats? have you implemented any of them and gotten other developers to also implement them? that's what it takes to get things changed, ya know...

Foremost, he should try to fix things that are actually broken. CHRS and TZUTC are not (although CHRS is slightly overengineered, but does the job).

For Fido, I see other problems like privacy/security and even message length where the existing technology really is not state of the art. Also, use of MIME etc. comes to mind when it comes to message content. But given the current state of Fido, I do not think that there will be any substatial technology changes at all. Also, because they are more likely to drive people away than to attract new users.

On the other hand, even the two-digit date is not pressing at all. If Fido still exists when that becomes relevant ...

Regards,
Tim
--- WinPoint 390.0
* Origin: Original WinPoint Origin! (2:240/1120.29)

On 2022 Jan 14 05:30:50, you wrote to me:

have you looked at any of the other PKT and packed message formats?

Type 2, 2+ and 2.2. 2.2 only works with one of my uplinks.

so none of the Type 3 or Type 10 formats?

+2 + +2 = +4

Fine for numbers but lousy for strings.

TZUTC1 + TZUTC2 = ?!?!?!?!?!?!

What in the name of strftime() is confusing you? You appear to be suffering from the same affliction as everyone east of prime meridian (castration?). +0000 is a string (N)ot (a) (N)umber (<- NaN). Stripping off the '+' character effectively corrupts it.

until you convert it to a number for the necessary math when needed ;)

really??

Yes. Basic programming skills inform me that strings are not numbers even if they look like numbers. The utc offset *is* a string ... or at least real life ones are.

yep... and at some point, their contents are converted from their string representation to some sort of numeric representation so they can be added or subtracted from a time value to give the time in another location...

)\/(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!"
... Age is a very high price to pay for maturity.
---
* Origin: (1:3634/12.73)

On 2022 Jan 14 15:13:50, you wrote to me:

have you looked at any of the other PKT and packed message formats?
have you implemented any of them and gotten other developers to also
implement them? that's what it takes to get things changed, ya
know...

Foremost, he should try to fix things that are actually broken. CHRS
and TZUTC are not (although CHRS is slightly overengineered, but does
the job).

agreed... to a point :)

For Fido, I see other problems like privacy/security and even message length where the existing technology really is not state of the art.

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

from FTS-0001...

1. Application Layer Data Definition : a Stored Message

Stored Message

Offset
dec hex
.-----------------------------------------------.
[...]
+-----------------------+-----------------------+
190 BE | text |
~ unbounded ~
| null terminated |
`-----------------------------------------------'
[...]
1. Presentation Layer Data Definition : the Packed Message

[...]
Packed Message

Offset
dec hex
.-----------------------------------------------.
[...]
+-----------------------+-----------------------+
34 22 | toUserName |
~ max 36 bytes ~
| null terminated |
+-----------------------+-----------------------+
| fromUserName |
~ max 36 bytes ~
| null terminated |
+-----------------------+-----------------------+
| subject |
~ max 72 bytes ~
| null terminated |
+-----------------------+-----------------------+
| text |
~ unbounded ~
| null terminated |
`-----------------------------------------------'

just saying ;)


)\/(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!"
... When you're the devil, women instantly suspect your motives. -Satan
---
* Origin: (1:3634/12.73)

Hey mark!

so none of the Type 3 or Type 10 formats?

None. What for? From what I've witnessed over the last two decades is that there is no official acceptance of type 2+ headers which from this angle looks to be the most used. Besides why tackle a new idea if we can't get the even the simplest things right such as telling the difference between a number and a string.

Just saying ... :-)

until you convert it to a number for the necessary math when
needed ;)

Sure. I'd appreciate seeing your routine for taking care of that, esecially considering given the potentially corrupted (eastern) utc offset. Myself I will continue ignoring it ... after I send this reply that is.

their string representation to some sort of numeric
representation so they can be added or subtracted from a time
value to give the time in another location...

You don't even have to do that if you use strftime() and a suitable offset.

TZ=UTC date --rfc-3339=sec --date="14 Jan 22 10:48:08 -0500"
2022-01-14 15:48:08+00:00

Doesn't that look much better? For the record coreutils' date app is 100% strftime compatible but strftime() can be readily compiled in c for example. The strftime function can be found in time.h.

Piece of cake when you follow real standards instead of poorly hacked and definetly corrupted "standard" such as demonstrated by fts-4008.002.

I will deal with CHRS when the appropriate time comes and given last year's performance I have serious doubts it will ever happen, nevermind in my lifetime.

Life is good,
Maurice

... Weorða ðe selfne godum dædum, ðenden ðin God recce.
Bring honour to yourself with good deeds, while God guides you.
--- GNU bash, version 5.1.8(1)-release (x86_64-moosile-linux-gnu)
* Origin: One of us @ (1:153/7001.2989)

On 2022 Jan 14 10:18:14, you wrote to me:

so none of the Type 3 or Type 10 formats?

None. What for? From what I've witnessed over the last two decades is that there is no official acceptance of type 2+ headers which from this angle looks to be the most used.

not all proposals are accepted or if accepted, stick around...

Besides why tackle a new idea

they're not new ideas... just no one, other than their originator, has looked at them and considered to actually implement them...

if we can't get the even the simplest things right such as telling the difference between a number and a string.

Just saying ... :-)

you really should take a closer look at strftime, then... somewhere inside it, there is a conversion from string to numerics and back to string again otherwise the hour in the time could not be added or subtracted from the hour in the offest string... think about it... just saying...

until you convert it to a number for the necessary math when
needed ;)

Sure. I'd appreciate seeing your routine for taking care of that,

trace out all the code in your strftime... i'm pretty sure you'll find something in there that does the conversion ;)

their string representation to some sort of numeric
representation so they can be added or subtracted from a time
value to give the time in another location...

You don't even have to do that if you use strftime() and a suitable offset.

strftime /HAS/ to convert from string to digit and back /somewhere/ within itself or a routine it makes use of... there's no other way to do math, my friend ;)

)\/(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!"
... The vegetarian has rejected a foundational principle of our culture.
---
* Origin: (1:3634/12.73)

Hey mark!

not all proposals are accepted or if accepted, stick around...

Too bad they missed out on the opportunity to not accept a few of them that stick around when they have no right to exist in the first place.

somewhere inside it, there is a conversion from string to
numerics and back to string again

No doubt. However it REQUIRES the first character in the string to be either a '+' (east) or a '-' (west). Note the REQUIRE and that is part and parcel of the offset ... which is always a string ... which is always NaN. Dropping the '+' character ist vorboten.

TZ=UTC date --rfc-3339=sec --date="14 Jan 22 20:27:36 0000"
date: invalid date '14 Jan 22 20:27:36 0000'
TZ=UTC date --rfc-3339=sec --date="14 Jan 22 20:27:36 +0000"
2022-01-14 20:27:36+00:00

just saying ...

Life is good,
Maurice

... Don't cry for me I have vi.
--- GNU bash, version 5.1.8(1)-release (x86_64-moosile-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

//Hello mark,//

on *14.01.22* at *16:07:18* You wrote in rea *FTSC_PUBLIC*
to *Tim Schattkowsky* about *"Unix point?"*.

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

I know, but this clash with the reality of many implementations (not including WP, at least up to ~2GB message length) makes the situation worse. What I have seen is that commonly messages are in practice split at slightly below 64k and I am not sure if any real world software bothers recombining them (WP does not). However, since this was mostly relevanted for gated emails, it is today probably of little practical interest anyway.

Regards,
Tim
--- WinPoint 390.0
* Origin: Original WinPoint Origin! (2:240/1120.29)

On 2022 Jan 14 20:27:36, you wrote to me:

not all proposals are accepted or if accepted, stick around...

Too bad they missed out on the opportunity to not accept a few of them that stick around when they have no right to exist in the first place.

that's your opinion... i won't even ask who it is you think assigns any so-called rights to any proposals' existence...

somewhere inside it, there is a conversion from string to numerics
and back to string again

No doubt.

thank you...

However it REQUIRES the first character in the string to be either a
'+' (east) or a '-' (west). Note the REQUIRE and that is part and
parcel of the offset ... which is always a string ... which is always
NaN.

you keep forgetting to add "in your chosen routine" to your statements... other routines that do the same or similar job do not have such a requirement...

Dropping the '+' character ist vorboten.

mmmhummm... no '+' here... plus you just said that it could be one of two specific characters so...

TZ=UTC date --rfc-3339=sec --date="14 Jan 2022 22:27:36 -0000"
2022-01-14 22:27:36+00:00

then there's this which also works just fine IF you like the ISO8601 format... some do not care for it...

TZ=UTC date --rfc-3339=sec --utc
2022-01-14 22:27:36+00:00

but you already know these things and are just trying to get your jollies arguing about something... meh... i'm done because it isn't worth it, it is a very old argument (like 2 decades now you've been going on about this??), and simply said, it is not what the developer who wrote the accepted spec decided to use...


PS: yes, i did time my use of the above 2nd date call (with --utc) to match the example naturally :)

PPS: i also note your use of a two-digit year in your examples ;)

PPPS: the resulting '+' or '-' on the time zone is likely due to the use of a boolean array where only true or false are allowed...

eg:
const
FmtOffset: string = '%.02d%.02d';
Sign: array[Boolean] of Char = ('+', '-');

var
LocalTimeOffset: Integer;

begin
LocalTimeOffset := GetLocalTimeOffset;
Writeln (FormatDateTime('YYYY MMM DD hh:mm:ss', Now) + ' ' + Sign[LocalTimeOffset>0],
Format(FmtOffset, [LocalTimeOffset div MinsPerHour, LocalTimeOffset mod MinsPerHour]));
end.

2022 Jan 14 17:27:36 -0500


)\/(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!"
... Remember: Landings should always equal takeoffs!
---
* Origin: (1:3634/12.73)

On 2022 Jan 14 18:31:56, you wrote to me:

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

I know,

i thought you probably did :)

but this clash with the reality of many implementations (not including
WP, at least up to ~2GB message length) makes the situation worse.
What I have seen is that commonly messages are in practice split at 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 :)

and I am not sure if any real world software bothers recombining them
(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...

However, since this was mostly relevanted for gated emails, it is
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)

Hey mark!

i'm done because it isn't worth it

Amen.

Life is good,
Maurice

... Don't cry for me I have vi.
--- GNU bash, version 5.1.8(1)-release (x86_64-moosile-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hi mark,

On 2022-01-14 18:23:42, you wrote to Tim Schattkowsky:

... 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 :)

You probably mean 2M ! It was never in the G size...

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Wilfred wrote (2022-01-15):

Hi mark,

On 2022-01-14 18:23:42, you wrote to Tim Schattkowsky:

... 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 :)

You probably mean 2M ! It was never in the G size...

inflation-adjusted 2M is around 2G nowadays ;-)

---
* Origin: Birds aren't real (2:280/464.47)

On 2022 Jan 15 11:29:10, you wrote to me:

... 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 :)

You probably mean 2M ! It was never in the G size...

oops! you're right :LOL:

)\/(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!"
... IF I HEAR THAT WORD ONE MORE TIME, I'M GONNA LEVEL THIS PLACE.
---
* Origin: (1:3634/12.73)

//Hello Oli,//

on *15.01.22* at *11:11:01* You wrote in rea *FTSC_PUBLIC*
to *Wilfred van Velzen* about *"Unix point?"*.

Wilfred wrote (2022-01-15):

Hi mark,

On 2022-01-14 18:23:42, you wrote to Tim Schattkowsky:

... 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 :)

You probably mean 2M ! It was never in the G size...

Which bringst me to the point that I simply do not understand the memory usage of certain kinds of applications nowadays. For some things like web browsers, it is at least obvious that there is potential to abuse a lot of memory. For others, like many simple business applications, I dont see any reason why something the would have easily fit a C64 nowadays instally to GBs on disk and requires GBs to operate.

Regards,
Tim
--- WinPoint 390.1
* Origin: Original WinPoint Origin! (2:240/1120.29)

Hi Tim,

On 2022-01-15 16:57:32, you wrote to Oliver Deiter:

You probably mean 2M ! It was never in the G size...

Which bringst me to the point that I simply do not understand the memory usage of certain kinds of applications nowadays. For some things like web browsers, it is at least obvious that there is potential to abuse a lot of memory. For others, like many simple business applications, I dont see any reason why something the would have easily fit a C64 nowadays instally to GBs on disk and requires GBs to operate.

Because they use java for instance? That comes with a ton of "needed" libraries...

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Which bringst me to the point that I simply do not understand the memory usage of certain kinds of applications nowadays. For some things like web browsers, it is at least obvious that there is potential to abuse a lot
of memory. For others, like many simple business applications, I dont see any reason why something the would have easily fit a C64 nowadays
instally to GBs on disk and requires GBs to operate.

Faking disc-activity in memory for speedy access ...

\%/@rd

--- DB4 - Jan 09 2022
* Origin: Hou het veilig, hou vol. Het komt allemaal weer goed (2:292/854)