Hi all, there hasn't been much going on but the FTSC did release an INA flag cleanup. Mostly to get the position of the flag in a consistant location. Makes it easier for programmers.

xxcarol
--- SBBSecho 2.12-Win32
* Origin: SHENK'S EXPRESS telnet://shenks.synchro.net (1:275/100)

Good ${greeting_time}, Carol!

15 Oct 2017 20:29:30, you wrote to All:

Hi all, there hasn't been much going on but the FTSC did release
an INA flag cleanup. Mostly to get the position of the flag in a consistant location. Makes it easier for programmers.

Any flag may be in any position in the tail of a nodelist line.
You may deny it, but that's the truth.


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin.ru!gremlin; +vii-cmiii-cmlxxvii-mmxlviii

... :wq!
--- /bin/vi
* Origin: http://openwall.com/Owl (2:5020/545)

On 2017 Oct 16 10:23:00, you wrote to Carol Shenkenberger:

Hi all, there hasn't been much going on but the FTSC did release an
INA flag cleanup. Mostly to get the position of the flag in a
consistant location. Makes it easier for programmers.

Any flag may be in any position in the tail of a nodelist line. You
may deny it, but that's the truth.

no, that's your browbeating and forced position... there is no so-called ""truth"" in it at all... just you and a few others demanding and getting your way... consider what happens if everyone in the net told you that you are/were wrong and started using flags in position dependant ways? then where would you be? DDoSing others and taking down services they offer? you've said that you would do as much... especially if someone tried to put up a similar service to binkp.net...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Do you remember why we went to the hospital?
---
* Origin: (1:3634/12.73)

Hello Carol!

15 Oct 17 20:29, you wrote to All:

Hi all, there hasn't been much going on but the FTSC did release an INA flag cleanup. Mostly to get the position of the flag in a consistant location. Makes it easier for programmers.

Yes lets go back to punchcards and write Fidonet software in COBOL.

I fail to see the gain. If a programmer cannot find a substring within a
string, I fear for the other code he writes.

Having values in a fixed location, requires that they are always there,
if they are always there there is no need to have a flag attached to them.

The last position dependent value in a nodelist line is the baudrate, it
has no flag and can only be found by its position in the line.


Kees

--- GoldED+/LNX 1.1.5
* Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)

Hello mark!

16 Oct 17 05:02, you wrote to Alexey Vissarionov:

no, that's your browbeating and forced position... there is no so-called ""truth"" in it at all... just you and a few others demanding and getting your way... consider what happens if everyone in the net told you that you are/were wrong and started using flags in position dependant ways? then

Sounds like a pot blaming a kettle that he is ......

Kees

--- GoldED+/LNX 1.1.5
* Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)

On 2017 Oct 16 12:42:40, you wrote to me:

no, that's your browbeating and forced position... there is no
so-called ""truth"" in it at all... just you and a few others
demanding and getting your way... consider what happens if everyone
in the net told you that you are/were wrong and started using flags
in position dependant ways? then

Sounds like a pot blaming a kettle that he is ......

not in this case...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... There are 40 kinds of lunacy, but only 1 kind of common sense.
---
* Origin: (1:3634/12.73)

Hello Carol,

On Sunday October 15 2017 20:29, you wrote to All:

Hi all, there hasn't been much going on but the FTSC did release an
INA flag cleanup. Mostly to get the position of the flag in a
consistant location. Makes it easier for programmers.

You must have been on summer sabbatical leave when FTS-5001 was updated earlier
this year.

From FTS-5001.006:

Unless otherwise stated, flags are not position or order dependent,
with the exception that User Flags must follow Normal Flags.

There is no "otherwise stated" for the INA flag and so it is NO location specified for it.

http://ftsc.org/docs/fts-5001.006

Please stop speading misinformation.


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: http://www.vlist.org (2:280/5555)

Hello mark!

16 Oct 17 09:24, you wrote to me:

no, that's your browbeating and forced position... there is no
so-called ""truth"" in it at all... just you and a few others
demanding and getting your way... consider what happens if everyone
in the net told you that you are/were wrong and started using flags
in position dependant ways? then

Sounds like a pot blaming a kettle that he is ......

not in this case...

Ofcourse.

Kees

--- GoldED+/LNX 1.1.5
* Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)

On 2017 Oct 16 22:16:20, you wrote to me:

no, that's your browbeating and forced position... there is no
so-called ""truth"" in it at all... just you and a few others
demanding and getting your way... consider what happens if everyone
in the net told you that you are/were wrong and started using flags
in position dependant ways? then

Sounds like a pot blaming a kettle that he is ......

not in this case...

Ofcourse.

you and most others don't know the background, kees... sorry...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... But the manifest read 'Farm Equipment'
---
* Origin: (1:3634/12.73)

On 15 Oct 17 20:29:30, Carol Shenkenberger said the following to All:

Hi all, there hasn't been much going on but the FTSC did release an INA fla cleanup. Mostly to get the position of the flag in a consistant location. Makes it easier for programmers.

I doubt that is the case and I seriously doubt there is a mailer or nodelist compiler that cannot process flags beyond the baudrate unless they sit in a particular position.

Even if there was, it is almost certain that such product would not know what an INA flag is (or maybe even the CM or MO flag for that matter). Two outcomes in that case - the nodelist compile fails, or the flag is ignored.

It is very easy to write a nodelist compiler. String parsing is programming-101. Expecting flags at set locations is sheer morbid laziness.

Nick

--- Renegade vY2Ka2
* Origin: Joey, do you like movies about gladiators? (1:229/426)

Hi Carol!

15 Oct 2017 20:29, from Carol Shenkenberger -> All:

Hi all, there hasn't been much going on but the FTSC did release an
INA flag cleanup.

???

What are you talking about?
One FTSC member was writing about something like this.
Can you point me where the FTSC released something liket that?
If it exists, I completely missed it!

CU, Ricsi

--- GoldED+/LNX
* Origin: Better a bird in the hand than one overhead. (2:310/31)

Re: Recent stuff
By: Alexey Vissarionov to Carol Shenkenberger on Mon Oct 16 2017 10:23 am

Hi all, there hasn't been much going on but the FTSC did release
an INA flag cleanup. Mostly to get the position of the flag in a
consistant location. Makes it easier for programmers.

Any flag may be in any position in the tail of a nodelist line.
You may deny it, but that's the truth.

I'm not denying it, only noting that the reason was for a little better consistency.
Carol
--- SBBSecho 2.12-Win32
* Origin: SHENK'S EXPRESS telnet://shenks.synchro.net (1:275/100)

Re: Recent stuff
By: Richard Menedetter to Carol Shenkenberger on Sat Oct 21 2017 09:50 pm

Hi all, there hasn't been much going on but the FTSC did release an
INA flag cleanup.

???

What are you talking about?
One FTSC member was writing about something like this.
Can you point me where the FTSC released something liket that?

Humm, must have misread it then. I thought I saw a tidy up there.

Carol
--- SBBSecho 2.12-Win32
* Origin: SHENK'S EXPRESS telnet://shenks.synchro.net (1:275/100)

Re: Recent stuff
By: mark lewis to Alexey Vissarionov on Mon Oct 16 2017 05:02 am

Hi all, there hasn't been much going on but the FTSC did release an
INA flag cleanup. Mostly to get the position of the flag in a
consistant location. Makes it easier for programmers.

Any flag may be in any position in the tail of a nodelist line. You
may deny it, but that's the truth.

no, that's your browbeating and forced position... there is no so-called ""truth"" in it at all... just you and a few others demanding and getting your way... consider what happens if everyone in the net told you that you are/were wrong and started using flags in position dependant ways? then where would you be? DDoSing others and taking down services they offer? you've said that you would do as much... especially if someone tried to put up a similar service to binkp.net...

LOL, I think I see where I tripped. Z1 went positional and i mixed it up. My apologies folks.

I had one node that I'd copied the entry from their previous listing that Mike Luko pointed to me. I fixed it.

Carol
--- SBBSecho 2.12-Win32
* Origin: SHENK'S EXPRESS telnet://shenks.synchro.net (1:275/100)

Good ${greeting_time}, Carol!

29 Oct 2017 11:43:56, you wrote to me:

Hi all, there hasn't been much going on but the FTSC did release
an INA flag cleanup. Mostly to get the position of the flag in a
consistant location. Makes it easier for programmers.

Any flag may be in any position in the tail of a nodelist line.
You may deny it, but that's the truth.

I'm not denying it, only noting that the reason was for a little
better consistency.

That doesn't affect consistency: the nodelist lines are parsed by standard functions like strtok() or split(), which don't care of fields order. Then, fields are checked for valid flags, which are then parsed to key:value list.

Have you ever wrote something using imperative algorithmic language? Or your experience consist only of databases? :-)


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin.ru!gremlin; +vii-cmiii-cmlxxvii-mmxlviii

... GPG: 8832FE9FA791F7968AC96E4E909DAC45EF3B1FA8 @ hkp://keys.gnupg.net
--- /bin/vi
* Origin: http://openwall.com/Owl (2:5020/545)