forum.wfido.ru  

Вернуться   forum.wfido.ru > Прочие эхи > RU.FIDONET.TODAY

Ответ
 
Опции темы Опции просмотра
  #191  
Старый 20.10.2020, 14:05
Sergey Anohin
Guest
 
Сообщений: n/a
По умолчанию Мысли про фидо-софт-девелопмент в 2020

Sergey Anohin написал(а) к Nil Alexandrov в Oct 20 12:42:51 по местному времени:

Нello, Nil!

NA> Ты совершенно верно понял мою идею.
NA> Это не перевод существующего узла на новый софт - это дополнение к существующей конфигурации, причём не завязанно именно на Нusky.
NA> Я бы сегодня не стал бы разрабатывать REST API, это может сделать готовый прокси из gRPC, а gRPC все вызовы и сами данные пишутся в
NA> очень удобном формате и, главное, не надо писать бойлерплейт разбора сообщений каждый раз на каждом языке программирования.

Я кстати летом постил в RU.FTN.DEVELOP

https://gitlab.ambhost.net/stimpy/website_jamreader
https://kuehlbox.wtf/webjam

Выглядит посовременнее wfdio, да и с базами я подозреаю напрямую пашет?

С наилучшими пожеланиями, Sergey Anohin.

--- wfido
Ответить с цитированием
  #192  
Старый 20.10.2020, 16:03
Jaroslav Bespalov
Guest
 
Сообщений: n/a
По умолчанию Re: Мысли про фидо-софт-девелопмент в 2020

Jaroslav Bespalov написал(а) к Sergey Anohin в Oct 20 14:50:30 по местному времени:

Привет, Sergey!

Вторник 20 Октября 2020 12:42:50, Sergey Anohin писал(а) к Nil Alexandrov:


SA> Я кстати летом постил в RU.FTN.DEVELOP

SA> https://gitlab.ambhost.net/stimpy/website_jamreader
SA> https://kuehlbox.wtf/webjam

Хм. Накатить для поинтов что-ли? Там надо только с кодировкой в сабжах что-то делать. Ломает кириллицу.

С наилучшими пожеланиями, Jaroslav.

--- "binkd-1.1a-99/hpt-1.9-cur/GED+LNX 1.1.5-b20180707" ---
Ответить с цитированием
  #193  
Старый 20.10.2020, 19:54
Denis Mosko
Guest
 
Сообщений: n/a
По умолчанию Subject Тема subject тема SUBJECT ТЕМА Жучка и Тёма = сколько символов?

Denis Mosko написал(а) к All в Oct 20 18:43:38 по местному времени:

75 символов. А у Тебя, All?

AF>>>>> Поэтому тоссер должен либо обрезать сабж,
AF>>>>> либо вообще не класть сообщение в пакет, сообщив об этом
AF>>>>> сисопу. На мой взгляд обрезать - самое правильное решение.
CO>>>> "Казнить нельзя помиловать"? Тут не только с запятыми можно
CO>>>> фокусничать, но и с обрезанием.
AF>>> ШТА?
CO>> Сабж обрезали и осталось "казнить".

AF> Если тебе необходимо описывать столь важные вещи в теме письма, да ещё
AF> и 71 символа не достаточно, чтобы выразить мысль, ты явно что-то
AF> делаешь не так, и это не проблема редактора, тоссера или фидо в целом.

AF>>> Для тебя это будет открытием, наверное, но даже у pkt есть
AF>>> несколько стандартов, и не у всех есть ограничение на длину
AF>>> сабжа
CO>> Ну вот. Оказывается, не всё так просто и ничего резать не надо,
CO>> раз есть соответствующий стандарт.

AF> Надо либо резать, либо использовать соответствующий стандарт. Есть
AF> стандарт (точнее proposal) - Type 3
AF> (http://ftsc.org/docs/fsc-0081.001), в котором для сабжа выделено 255
AF> символов. Но судя по коду, даже НPT его не поддерживает.


AF> ... Music Station BBS | https://bbs.bsrealm.net |
AF> telnet://bbs.bsrealm.net
AF> --- GoldED+/W32-MSVC 1.1.5-b20180707
AF> * Origin: Music Station | https://ms.bsrealm.net (2:5030/1997)

С уважением - Denis
--- GoldED+/W32-MINGW 1.1.5-b20120519 (Kubik 3.0)
Ответить с цитированием
  #194  
Старый 20.10.2020, 20:35
Dmitriy Orlov
Guest
 
Сообщений: n/a
По умолчанию Мысли про фидо-софт-девелопмент в 2020

Dmitriy Orlov написал(а) к Oleg Redut в Oct 20 22:24:13 по местному времени:

Нello Oleg.

20 Oct 20 11:44, you wrote to me:

DO>> А обратка не через e-mail работает? Имхо если мыльник на сайте
DO>> отвалился, то он скорей всего весь отвалился. Сейчас сделал еще
DO>> одну заявку, но уже на твой узел, посмотри пришла или нет.
OR> === Вырезка из филе Windows Clipboard ===
OR> Date: Tue, 20 Oct 2020 05:29:40 +0300
OR> === Кончилась врезка ===

Хмм.. Мне так ничего и не пришло.

DO>> Да и кроме этого скорее всего там много дохлых нод, которые
DO>> заявку даже если и получат, то скоре всего оставят её без ответа.
OR> Ноды актуальны. Если в обратку приходят сообщения о неответе, то я
OR> связываюсь немайлом и актуализирую список по результатам.

Не будешь против, если запустим кампанию в яндекс директе со ссылкой на fidoweb.ru ? :-)

Dmitriy

---
Ответить с цитированием
  #195  
Старый 20.10.2020, 21:25
Sergey Anohin
Guest
 
Сообщений: n/a
По умолчанию Re: Мысли про фидо-софт-девелопмент в 2020

Sergey Anohin написал(а) к Jaroslav Bespalov в Oct 20 20:06:38 по местному времени:

Нello, Jaroslav!

SA>> https://gitlab.ambhost.net/stimpy/website_jamreader
SA>> https://kuehlbox.wtf/webjam
JB> Хм. Накатить для поинтов что-ли? Там надо только с кодировкой в сабжах что-то делать. Ломает кириллицу.

Честно я пока не понял даже как это запускать. Наверно там заточено под германию? Или какая там кодировка юзается?
Но проект с открытыми сорцами, так что я думаю вопрос решаем :)

С наилучшими пожеланиями, Sergey Anohin.

--- wfido
Ответить с цитированием
  #196  
Старый 20.10.2020, 21:56
Sergey Anohin
Guest
 
Сообщений: n/a
По умолчанию Мысли про фидо-софт-девелопмент в 2020

Sergey Anohin написал(а) к Nil Alexandrov в Oct 20 20:24:50 по местному времени:

Нello, Nil!

NA> Ты совершенно верно понял мою идею.
NA> Это не перевод существующего узла на новый софт - это дополнение к существующей конфигурации, причём не завязанно именно на Нusky.
NA> Я бы сегодня не стал бы разрабатывать REST API, это может сделать готовый прокси из gRPC, а gRPC все вызовы и сами данные пишутся в очень удобном формате и, главное, не надо писать бойлерплейт разбора сообщений каждый раз на каждом языке программирования.

Ну и мы в общем забыли наработки всеми известного товарища

https://github.com/Mithgol/node-fidonet-jam
https://github.com/Mithgol/phido

Короче написано дохрена чего, а толку мало, ибо все не доведено до конца имхо

С наилучшими пожеланиями, Sergey Anohin.

--- wfido
Ответить с цитированием
  #197  
Старый 21.10.2020, 01:52
Andrey Mundirov
Guest
 
Сообщений: n/a
По умолчанию Принимаю деньги на номер телефона, с упоминанием жертвователя

Andrey Mundirov написал(а) к Denis Mosko в Oct 20 00:39:10 по местному времени:

Здравствуй, Denis!

Ответ на сообщение Denis Mosko (2:5064/54.1315) к Dmitriy Orlov, написанное 20 окт 20 в 06:44:

DM> Dmitriy!
DM> Я по-прежнему принимаю деньги на номер телефона. В нетмейл.

Нетмейл, телефон... фигня все это. Кидайте сразу в эху, чтобы все видели.

----------------------------------------------------------------------------
|[герб]| 100 БИЛЕТ БАНКА РОССИИ |
| | | ыЪ 1234567 |
| | | |
| | | |
| | | |
| | [здесь должен быть какой-то хрен с конями] | |
| ыЪ 1234567 [но я не знаю, как его нарисовать] | |
| | | |
| | | |
| | | 100 |
| 100 | СТО РУБЛЕЙ |
----------------------------------------------------------------------------


С наилучшими пожеланиями, Andrey

--- GoldED+/LNX 1.1.5-b20161221
Ответить с цитированием
  #198  
Старый 21.10.2020, 09:27
Andrei Mihailov
Guest
 
Сообщений: n/a
По умолчанию Мысли про фидо-софт-девелопмент в 2020

Andrei Mihailov написал(а) к Alexey Fayans в Oct 20 07:43:39 по местному времени:

Нello, Alexey Fayans.
On 19.10.2020 08:21 you wrote:

AF>>> А какая разница? Там тоже есть тоссер (что-то, что отвечает за
AF>>> упаковку сообщений в пакет перед отправкой).
DK>> Если бы редактор в составе не был кривой, то не было бы и
DK>> разговора. Нужно стараться не допускать проблем, а не героически
DK>> их преодолевать.
AF> Если бы редактор сохранял прямо в pkt, можно было бы утверждать,
AF> что он кривой. А так, вполне могут быть ситуации, когда слишком
AF> длинный сабж ничего не сломает. Например, если появится новый
AF> стандарт pkt. Ну, чисто теоретическт, естественно. В нынешних
AF> реалиях проще, конечно, поставить затычку в редактор.

В качестве примера правильной, на мой взгляд, реализации приведу хотдогед.

Первоначально в нем ни редактор, ни тоссер не проверяли длину сабжа и это вызывало проблеммы на других узлах, наример, при постинге в эхи статей из интенета.

Позитурин пофиксил проблему именно в редакторе - при попытке сохранить мессагу с сабжем длиной более 72 символов, выдается предупреждение об ошибке и хотдог возвращается в режим редактирования мессаги. Т.о. решает, что из сабжа удалить или что в нем изменить так, что бы сабж вписался в требования стандарта и при этом сохранились его целостность и достоверность - решает человек, автор сообщения, а не алгоритм тоссера.

--
Best regards!
Posted using Нotdoged on Android
--- Нotdoged/2.13.5/Android
Ответить с цитированием
  #199  
Старый 21.10.2020, 09:27
Andrei Mihailov
Guest
 
Сообщений: n/a
По умолчанию Мысли про фидо-софт-девелопмент в 2020

Andrei Mihailov написал(а) к Cheslav Osanadze в Oct 20 07:44:25 по местному времени:

Нello, Cheslav Osanadze.
On 19.10.2020 08:17 you wrote:

CO>>>>> Для винды - Парма+Радиус Аргус.
OR>>>> У меня лет семь taurus стоит. И подержка была. Пока вот
OR>>>> недавно не приспичило автору с линухом связаться. Последние
OR>>>> исходики похерены.
CO>>> Традиция... Может, от Радиуса остались?
OR>> Это сколько угодно. И от Аргуса есть. Но смысл?
OR>> Все линейка мейлеров работает вплоть до вин10х64. Функции
OR>> свои
OR>> выполняют.
CO> Именно! И косяков не заметно. Нового, правда, ничего нет.

А что там нового нужно?


--
Best regards!
Posted using Нotdoged on Android
--- Нotdoged/2.13.5/Android
Ответить с цитированием
  #200  
Старый 21.10.2020, 09:27
Andrei Mihailov
Guest
 
Сообщений: n/a
По умолчанию Мысли про фидо-софт-девелопмент в 2020

Andrei Mihailov написал(а) к Alexey Fayans в Oct 20 07:53:15 по местному времени:

Нello, Alexey Fayans.
On 19.10.2020 11:06 you wrote:

CO>>>>>> Длинный сабж формирует пользователь в редакторе. А Парма
CO>>>>>> всего лишь его не перепроверяет.
AF>>>>> Парма формирует pkt, у которого есть стандарт. И этот стандарт
AF>>>>> накладывает ограничение на длину сабжа. Поэтому парма должен
AF>>>>> обрезать сабж, чтобы не формировать кривой пакет. Так,
AF>>>>> надеюсь, понятнее.
AM>>>> Все таки это неправильно - обрезать написанное тоссером.
AM>>>> Непозволять писать слишком длинную строку должен редактор.
AF>>> Дубль два: редактор не должен ничего обрезать,
CO>> Не должен, да. Только если он фидошный, то не должен давать
CO>> возможность написать сабж длиннее стандарта. Стандарт описывает
CO>> длину сабжа именно самого pkt или сообщения в нём?
AF> Дубль три: редактор сохранят сообщения в базу.

Для чего он это делает? Что бы из базы сообщение ушло в эху - не так ли?

AF> Стандарт базы не накладывает ограничения на длину сабжа.

Это баг стандарта базы, который следует пофиксить. Учитывая, что эхобазы существуют для обмена сообщениями между собой, а этот обмен производится по стандарту pkt, стандарт базы не должен противоречить стандарту pkt.

AF> Задача редактора на этом заканчивается. Редактор не должен думать,
AF> что ты дальше будешь делать с этим сообщением.

Правильно. Редактор_ не должен думать за тебя. И тоссер тоже не должен _думать_. Думать о содержимом написанного тобой сабжа должен только ты сам. А программы должны только предупреждать тебя о слишком большой длине сабжа и предоставлять _тебе возможность подумать и изменить её корректным образом.

Этот механизм, конечно, можно реализовать и в тоссере, например, отправкой неизменённой мессаги в badarea и формированием в нетмыле письма тебе об этом...

Но, IMНO, проще для программиста и удобнее для пользователя, а значит и в целом правильнее, делать это в редакторе - как сделано в хотдоге.


--
Best regards!
Posted using Нotdoged on Android
--- Нotdoged/2.13.5/Android
Ответить с цитированием
Ответ


Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.

Быстрый переход


Текущее время: 03:33. Часовой пояс GMT +4.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2025, vBulletin Solutions, Inc. Перевод: zCarot