= Сообщение: 1800 из 5336 ========================================= RU.HUSKY = От : Evgeny Vetrov 2:5037/7 05 May 16 06:51:10 Кому : Michael Dukelsky 05 May 16 06:51:10 Тема : Баг в реализации Jam FGHI : area://RU.HUSKY?msgid=2:5037/7+572ac8b5 На : area://RU.HUSKY?msgid=2:5020/1042+572979ca = Кодировка сообщения определена как: CP866 ================================== Ответ: area://RU.HUSKY?msgid=2:5020/1042+572ad47e ============================================================================== Hello Michael.
EV>> Речь идет о echomail. EV>> В этом случае orig (отправитель) это всегда аплинк эхи, а dest EV>> (всегда "ты"). MD> С какой стати? Здесь же рассматривается не pkt, а эхобаза в формате MD> JAM. Так что orig - это тот, кто написал сообщение.
EV>> Куда вы деваете эти данные не очень интересно, смысловой EV>> нагрузки они не несут.
По наводке Vladimir Fyodorov потратил вчера 2 часа своего времени для того чтобы разобраться, почему в msged orig заполнено правильным адресом. Как мне казалось если проект использует smapi то и глюк в smapi должен наследоваться. Оказывается msged как только считывает сообщение из *эхи* сразу идет и ищет строчку "* Origin". И получается, что в структуре сообщения в orig адрес из "* Origin", а в dest адрес из "^aMSGID:"
Согласно старинной русской мудрости "Утро вечера мудренее" лег спать. И утром мне в голову пришла следующая мысль. Зачем smapi занимается подменой данных прочитанных из базы? В моем проекте это конечно упрощает код. Но IMHO когда читаешь базу нужно получить именно то, что в базе записано.
Я не знаю к каким последствиям в других проектах приведет удаление данного "интеллекта", но может это самое правильное решение?
И опять же читаешь сообщения из базы чаще чем пишешь. Может этот интеллект перенести в функцию записи в базу?
