Добро пожаловать, Гость. Пожалуйста авторизуйтесь здесь.
FGHIGate на GaNJa NeTWoRK ST@Ti0N - Просмотр сообщения в эхоконференции FTSC_PUBLIC
Введите FGHI ссылку:


Присутствуют сообщения из эхоконференции FTSC_PUBLIC с датами от 13 Sep 13 18:57:24 до 01 Apr 24 01:17:44, всего сообщений: 7124
Ответить на сообщение К списку сообщений Предыдущее сообщение Следующее сообщение
= Сообщение: 5296 из 7124 ====================================== FTSC_PUBLIC =
От   : Nicholas Boel                    1:154/10           18 Dec 20 18:56:04
Кому : Andrew Leary                                        18 Dec 20 18:56:04
Тема : alternative DateTime (ref: fts-0001.016)
FGHI : area://FTSC_PUBLIC?msgid=1:154/10+5fdd56d1
На   : area://FTSC_PUBLIC?msgid=1:320/219@fidonet+5fdcda43
= Кодировка сообщения определена как: UTF-8 ==================================
Ответ: area://FTSC_PUBLIC?msgid=1:320/219@fidonet+5fdd9f83
==============================================================================
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)

К главной странице гейта
Powered by NoSFeRaTU`s FGHIGate
Открытие страницы: 0.040894 секунды