Text 11732, 116 rader
Skriven 2020-12-18 18:56:04 av Nicholas Boel (1:154/10)
  Kommentar till text 11729 av Andrew Leary (1:320/219)
Ärende: alternative DateTime (ref: fts-0001.016)
================================================
Hello Andrew,

On Fri Dec 18 2020 11:32:54, Andrew Leary wrote to Maurice Kinal:

 AL> Hello Maurice!

 AL> 18 Dec 20 06:36, you wrote to me:

 MK>> Just a little something to brighten your day and perhaps spark
 MK>> much needed participation in this particular echoarea, or
 MK>> whatever the kids are calling it these days.

 MK>> proposed DateTime = a string 19 bytes long.
 MK>>                     Format = "YYYY-MM-DD hh:mm:ss" where,
 MK>>                               YYYY = four digit year
 MK>>                               MM   = two digit month ranging from
 MK>> 01 to 12
 MK>>                               DD   = two digit day ranging from
 MK>> 01 to 31
 MK>>                               hh   = two digit hour ranging from
 MK>> 00 to 23
 MK>>                               mm   = two digit minute ranging
 MK>> from 00 to 59
 MK>>                               ss   = two digit second ranging
 MK>> from 00 to 59

 MK>> Since there is no room for the UTC offset DateTime should be set
 MK>> to UTC in order to avoid confusion.  This format will ensure that
 MK>> the packed message is exactly the same byte length as specified
 MK>> in fts-0001.016 not counting the ASCII null charater that
 MK>> terminates the string as per packed MSG header specification for
 MK>> all header strings (eg To, From, subj, etc).

 AL> While I can see the merits of your proposal, it currently is not
 AL> implemented in any FidoNet compatible software.  Current FidoNet
 AL> software that parses the DateTime field would need to be updated to
 AL> support this new format.  For compatibility with existing FidoNet
 AL> software, implementations would need to be able to parse this format,
 AL> or the 2 other existing formats (FTS-1 or SeaDog.) In addition, to
 AL> avoid breaking existing software, this format should not be used in
 AL> packets without confirming that the software on the other end can
 AL>  process it correctly.

 AL> Given that many software packages used in FidoNet have been abandoned,
 AL> had their source code lost, or the authors are no longer available, it
 AL> is not likely that this format will succeed.

 AL> Your best shot is to convince the maintainers of existing packages
 AL> which are still being developed, such as HPT, D'Bridge, MBSEBBS,
 AL> Synchronet, and Mystic of the merits of your proposal, and get it
 AL> implemented.  Several of these packages are open source, so you could
 AL> conceivably implement it yourself and submit patches to the
 AL> maintainers for consideration.

 AL> As for the use of UTC in packet headers, again you are fighting an
 AL> uphill battle.  The TZUTC kludge line was created because the .MSG and
 AL> .PKT headers had no provision for timezone offsets.

 AL> Andrew

 AL> --- GoldED+/LNX 1.1.5-b20180707
 AL>  * Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)

THIS

This is exactly why Fidonet is dying at a rapid rate.

While the Husky project, Synchronet, Mystic, D'Bridge, MBSE continue to be
developed, they are limited in what they can actually do (to be honest, some
have already just gave up on "fidonet standards" and moved on to supporting way
more things than just FTN) in order to keep this backwards compatibility that
systems 30 years ago used.

Most of said systems that use/used 30 year old software are gone, if not
leaving shortly. If we actually want this to continue, we should probably at
some point leave said backwards compatibility systems behind and move forward.
In my recent experience, I've come across two types:

1) Old school people coming back around to see where the "scene" is at. These
seem to be the ones that once they see people are still using garbage like, oh
lemme come up with an example, IREX, they don't last long.

2) New generation looking for the old school retro BBS thing. These even
include college kids looking for some retro computing stuff. The only thing we
seem to be able to show them is that not much has changed, and we can't evolve.
So they exit stage left also.

This is why we're not growing, but rather declining.

We still have quite a few people developing for this technology. And a couple
willing to take things further. For fuck's sake why are there people trying to
hold them back every chance they get? People calling out software for being
"buggy" just because it's newly updated and they don't use it. THAT'S HOW
ADVANCEMENT WORKS! How about try it, test it, and give feedback on what can be
improved! 

It's seriously sad as fuck around here. I've taken long hiatuses from posting
just because I knew arguments would ensue I didn't give a shit to be involved
with. I'm a big fan of currently developed software, and have multiple systems
(some not on Fidonet) running here to test software and enjoy the fact that my
hobby when I was 15 years old (am now going to be 40 next month - and I don't
care to hear how long any of you have been here) is still progressing (albeit
at an alarmingly slow pace, pretty much due to the FTSC and or a select few
people that apparantly want Fidonet to just die already).

If you want Fidonet to die, or you don't care any more, or you want to run down
every new idea (even if it's actual code!) brought forth.. turn your system off
or redirect your IP addresses elsewhere.. We could probably gain more interest
and enthusiasm without you.

Regards,
Nick

... "Take my advice, I don't use it anyway."
--- GoldED+/LNX 1.1.5-b20181215
 * Origin: thePharcyde_ distribution system (Wisconsin) (1:154/10)