이것은 우리가 잠재적으로 할 수 있는 다양한 것들의 문을 열어줍니다. 예를 들어, 오래된 버전의 메시지에 대한 답장 메일을 거부하는 것 같은데요. 하지만 이건 상상력 발휘(imagineering)에 불과하며, 아마도 좋은 아이디어처럼 들리지만 반드시 그런 것은 아닙니다 
3개의 좋아요
아직 이 부분이 언급되지 않은 것 같으니, 반드시 처리해 주세요:
- 이메일에 “이전 답장” 섹션이 포함된 경우, (수신자에게 맞춤화된 처리를 수행하세요)
이전 답변이 정확히 무엇을 의미하는지, 그리고 수신자에게 더 구체적으로 맞춤화하려면 어떻게 해야 하는지 잘 모르겠습니다. 여기에서 자세히 설명한 일관된 Message-ID 전략과 어떻게 연결되는지 궁금합니다.
누군가 “이전 답변” 섹션을 받게 된다면, 일관된 메시지 ID를 사용하는 것을 완전히 포기해야 합니다. 여러 게시물을 하나의 이메일로 통합하고 있기 때문입니다! 여러 관점에서 모든 내용을 일관되게 식별하는 단일 메시지 ID는 존재하지 않습니다.
수정: 사실은 그냥 연결(concatenate)하면 되는 것 같습니다?
topic/1234/post/12345.also-12340-12339
또한, 이는 앞서 언급된 스팸 트리거를 더욱 심각하게 만듭니다. 동일한 메시지 ID로 구독 해지 링크를 바꾸는 것뿐만 아니라, 동일한 메시지 ID로 전송되는 서로 다른 버전에서 실제 단어가 포함되거나 제외되기 때문입니다.
Kane York, Discourse Meta에서 2022년 8월 2일 04:26:
누군가 “이전 답글” 섹션을 받게 되면, 일관된 메시지 ID를 사용하는 것을 완전히 포기해야 합니다: 여러 게시물을 하나의 이메일로 결합하고 있기 때문이죠!
이 부분에 대해 조금 더 자세히 설명해 주실 수 있나요? 이 경우 이메일은 어떤 모습인가요? 예시가 있나요?
여러 관점에서 모든 내용을 일관되게 식별하는 올바른 단일 메시지 ID는 존재하지 않습니다.
대부분의 용도에는 첫 번째 메시지 ID처럼 하나만 선택하는 것으로 충분합니다. 이 예시가 여전히 답글인 경우라면요.
수정: 사실 단순히 이들을 연결(concatenate)하면 되는 것 같습니다?
topic/1234/post/12345.also-12340-12339
저는 당신이 Discourse 포럼의 원본 게시물에 대한 어떤 종류의 참조와 메시지 ID를 혼동하고 있는 것 같다는 생각이 들기 시작합니다. 메시지 ID는 이메일 메시지를 식별합니다. 답글 게시물의 경우, In-Reply-To와 References의 메시지 ID는 관련 있는 이전 이메일 메시지의 message-id와 일치해야 합니다. 누군가 주제(topic)에 게시물을 작성하면, 이메일 사본을 요청한 사람들에게 이메일로 전송되는 해당 게시물의 모든 사본에는 동일한 메시지 ID가 있어야 합니다.
또한, 이는 앞서 언급된 스팸 트리거를 더욱 심각하게 만듭니다: 동일한 메시지 ID로 구독 취소 링크를 바꾸는 것뿐만 아니라, 동일한 메시지 ID로 전달되는 서로 다른 버전에서 실제로 포함되고 제외되는 단어가 있기 때문입니다.
이것이 게시물의 하단에 있는 "관리용 푸터(administrative footers)"라면 아무 문제도 없습니다.
우리가 같은 것에 대해 이야기하고 있는지 확신이 서지 않습니다.
그리고: 여기서 논의하고 있는 구체적인 스팸 트리거가 무엇인가요? 왜냐하면 현실 세계에서는 “조금 다른” 이메일 메시지가 끊임없이 발송되기 때문입니다.
감사합니다,
Cameron Simpson cs@cskk.id.au
1개의 좋아요
Kane은 이 옵션에 대해 이야기하고 있습니다:
사용자들은 대량의 충실성(fidelity)을 가진 이전 답변을 이메일 끝에 첨부받도록 선택할 수 있습니다.
저는 현재 이것을 배경 방사선(background radiation) 정도로 취급하고, 고유한 구독 취소 링크를 처리하는 방식과 유사하게 다루는 데에 만족합니다.
우리가 이미 합의에 도달했으므로, 여기서 더 이상의 진전을 막고 싶지는 않습니다.
(외관과 관련해서, 제 생각에는 꽤 혼란스러워 보이지만 일부 사용자들은 이것을 좋아합니다)
1개의 좋아요
Sam Saffron이 Discourse Meta를 통해 2022년 8월 2일 05:29에 작성:
[quote=“Cameron Simpson, post:51, topic:233499,
username:cameron-simpson”]
이 부분을 좀 더 자세히 설명해 주시겠어요? 이 경우 이메일은 어떤 형태인가요? 예시가 있나요?
[/quote]Kane은 이 옵션에 대해 이야기하고 있습니다:
사용자들은 높은 충실도로 이전 답변을 이메일 끝에 첨부받도록 선택할 수 있습니다.
아, 감사합니다.
현재로서는 이를 배경 방사선(background radiation)으로 간주하고, 고유한 구독 취소 링크를 다루는 방식과 유사하게 처리하는 것에 동의합니다.
저도 그렇게 생각하는 것이 맞을 것 같습니다. 제 생각에는 이는 RFC의 "게시자/저자의 원래 의도"라는 목표와 부합합니다. 이는 수반되는 부수적 정보일 뿐, 핵심 메시지는 다르지 않기 때문입니다.
감사합니다,
Cameron Simpson cs@cskk.id.au
2개의 좋아요
동의합니다. 계획대로 진행합시다. 저는 어제부터 변경 사항을 살펴보기 시작했으며, 이메일 수신기부터着手했습니다.
@cameron-simpson 참고로, 저는 현재 맡고 있는 다른 업무들과 이 작업을 병행하고 있습니다. 다음 주에 휴가를 가고, 9월 첫 두 주 동안에도 다시 휴가를 갈 예정이므로, 여기서 실질적인 진전이 보이기까지는 조금 시간이 걸릴 수 있습니다. 이 업무를 최우선으로 생각하고 있으며, 정기적인 업데이트를 작성해 두께를 드리겠습니다. 지금까지의 참여와 기여에 감사드립니다!
1개의 좋아요
Martin Brennan님이 Discourse Meta를 통해 2022년 8월 2일 07:06에 작성:
@cameron-simpson 참고로, 저는 이 작업을 현재 맡고 있는 다른 업무와 함께 진행하고 있습니다. 다음 주에는 휴가를 가고, 9월 첫 2주에도 다시 휴가를 가므로, 여기서 실질적인 진전이 보이기까지는 다소 시간이 걸릴 수 있습니다. 이 문제를 최우선으로 생각하고 있으며, 이곳에 정기적인 업데이트를 작성하도록 하겠습니다. 지금까지 참여와 기여에 대해 정말 감사드립니다!
감사합니다,
Cameron Simpson cs@cskk.id.au
@cameron-simpson 여행에서 돌아와서 이 작업에 다시 착수했는데, References와 In-Reply-To 시나리오에 대해 좀 더 명확한 설명을 듣고 싶어 이렇게 글을 남깁니다.
시나리오 1: 다른 게시물에 직접 답변하지 않고 Discourse 내에서 새 게시물을 생성할 때, 새 outbound_message_id 컬럼에 저장된 토픽 OP(최초 게시자)의 Message-ID를 References와 In-Reply-To 양쪽에 모두 사용해야 하나요?
시나리오 2: 한 게시물이 여러 다른 게시물에 동시에 답변하는 경우(인용을 통해 발생할 수 있음) In-Reply-To에는 어떤 게시물을 사용해야 하나요? 그리고 References에는 모든 게시물을 포함해야 하나요, 아니면 In-Reply-To로 선택한 단일 게시물만 포함해야 하나요? References에 OP 게시물의 Message-ID를 포함해야 하나요?
시나리오 3: 위와 유사하지만, 답변하는 대상은 단일 게시물로 한정하겠습니다. 게시물 B에 답변하고 있고, 이 B가 다시 게시물 A에 대한 답변인 경우, In-Reply-To는 단순히 게시물 B를 가리키고 References는 게시물 A, 게시물 B 순서로 되어야 하나요(물론 항상 게시물에서 outbound_message_id를 통해 Message-ID를 참조하는 전제에서)? References에서 답변 체인을 계속 위로 올라가야 하나요, 아니면 첫 번째 부모 게시물까지만 포함해야 하나요?
이것은 주로 RFC의 다음 인용문을 어떻게 해석하느냐의 문제이며, 주로 References에 영향을 미칩니다. References는 인용을 통한 직접적인 답변으로만 제한되는 것일까요, 아니면 OP를 항상 포함해야 할까요?
참고: 일부 구현에서는 “References:” 필드를 파싱하여 "토론의 스레드"를 표시합니다. 이러한 구현은 각 새 메시지가 단일 부모에 대한 답변이라고 가정하며, 따라서 “References:” 필드를 거꾸로 거슬러 올라가 해당 목록에 있는 각 메시지의 부모를 찾을 수 있다고 봅니다. 따라서, 여러 부모를 가진 답변에 대해 “References:” 필드를 구성하는 시도는 권장되지 않으며, 이를 수행하는 방법은 이 문서에서 정의되어 있지 않습니다.
Cameron님 감사합니다. 그사이 제가 정확하다고 생각하는 방식으로 진행하다가, Cameron님의 답변을 바탕으로 조정하겠습니다.
Martin Brennan가 Discourse Meta를 통해 2022년 8월 19일 03:48에 작성:
@cameron-simpson 여행에서 돌아온 후 이 작업에 다시 착수했고, 다른
References와In-Reply-To시나리오에 대해 좀 더 명확한 설명을 듣고 싶었습니다.시나리오 1: Discourse에서 다른 게시물에 직접 답변하지 않는 게시물을 생성할 때, 새
outbound_message_id컬럼에 저장된 토픽 OP(첫 게시물)의Message-ID를References와In-Reply-To양쪽에 그대로 사용해야 하는가요?
용어 관련 혼란이 있는 것 같습니다. 새 토픽의 OP의 경우, OP이므로 References나 In-Reply-To가 없어야 한다고 생각합니다.
기존 토픽에서 특정 이전 게시물을 인용하지 않는 게시물(제가 생각하기에 실제로 설명하고 계신 상황)의 경우, References와 In-Reply-To 각각에 OP의 Message-ID만 포함하면 됩니다. 말씀하신 내용과 정확히 일치합니다.
시나리오 2: 게시물이 여러 게시물에 동시에 답변하는 경우(인용을 통해 발생할 수 있음)
In-Reply-To에는 어떤 게시물을 사용해야 하나요?
[RFC 5322를 다시 읽어보며…]
In-Reply-To에는 답변하는 각 게시물의Message-ID가 포함되어야 합니다.References는 부모(*)의References에 부모의Message-ID를 추가한 것이어야 합니다.
따라서 In-Reply-To는 스레드에서 바로 이전 메시지만을 가리킵니다. 부모 게시물이 여러 개이면 여러 message-id가 포함되지만, 이는 직접적인 부모 게시물의 message-id만이어야 합니다.
References는 OP부터 이 게시물의 부모(*)까지의 전체 답변 체인을 추적하기 위한 것입니다. 따라서 부모까지의 스레드에 부모의 message-id를 추가하여 계산됩니다.
(*) 부모가 하나 이상인 경우: RFC에 따르면 이메일 클라이언트(리더)는 References가 OP부터 게시물까지의 단일 답변 스레드를 추적한다고 기대하는 경우가 많으므로, RFC에서는 모든 부모의 References를 병합하는 것을 명시적으로 권장하지 않습니다. 대신 하나만 선택해야 합니다. 개인적으로는 첫 번째로 인용된 부모 게시물을 선택하는 것이 좋다고 생각하지만, 이는 명확히 정책적 판단 사항입니다. 가장 유용하다고 생각하는 것을 선택하시면 됩니다.
시나리오 3: 위와 유사하지만, 답변하는 게시물은 단일 게시물로 한정하겠습니다. 게시물이 B에 답변하고, B가 다시 A에 대한 답변인 경우,
In-Reply-To는 단순히 B를 가리키고references는게시물 A, 게시물 B순서로 되어야 하는가요(물론 게시물의outbound_message_id를 통해 항상Message-ID를 참조하는 것은 당연합니다)?References의 경우 답변 체인을 계속 위로 올라가야 하는지, 아니면 첫 번째 부모에서 멈추어야 하는가요?
In-Reply-To는 정확히 한 단계 위를 가리킵니다. 따라서 이 시나리오에서는 부모 게시물의 Message-ID만 포함됩니다.
References는 OP부터 이 메시지까지의 체인입니다.
이는 주로 RFC의 이 인용문을 어떻게 해석하느냐에 따라 달라지며, 주로
References에 영향을 미칩니다 – 직접적인 인용을 통한 답변으로만 제한되는지, 아니면 항상 OP를 포함해야 하는지.
항상 OP에서 시작해야 합니다. 이전 모든 게시물이 이렇게 했다면, 부모의 References에 부모 message-id를 붙여넣기만 하면 전체 체인을 무료로 얻을 수 있습니다.
“레거시” 메시지를 다룬다면 트리를 위로 거슬러 올라갈 수 있습니다. 또는 매번 그렇게 결정할 수도 있습니다. 아니면 앞으로는 괜찮다고 보고, 부모에 References가 있으면 그걸 가져오기로 결정할 수도 있습니다. 저는 이것이 데이터베이스에 무엇을 저장하기로 결정하느냐에 따라 달라진다고 생각합니다.
In-Reply-To가 직접적인 부모 계보를, References가 OP까지의 선을 가리키도록 목표를 설정하고 있다면, 문제는 없을 것입니다.
감사합니다,
Cameron Simpson cs@cskk.id.au
2개의 좋아요
네, 제가 설명드린 것이 바로 그 것입니다. 감사합니다.
감사합니다. 결국 답은 – 인용된 단일 게시물을 선택하여 이를 부모로 사용(처음 인용된 것이든 가장 최근에 생성된 것이든, 하나를 선택하는 것이 중요할 뿐)하고, 이를 In-Reply-To에 사용하며, References에는 이를 포함하여 OP까지의 모든 부모 체인을 사용하는 것입니다.
알겠습니다. 이해가 갑니다.
모든 것이 명확해졌습니다. 당신의 답변은 제가 기대했던 내용 그대로였습니다. 수동 테스트를 시작하기 전에 한 번 더 확인하고 싶었을 뿐입니다. 빠른 답변에 감사드립니다 
1개의 좋아요
@cameron-simpson 설명대로 작동하는 것 같습니다. mutt를 설정해 두었고, 스레딩도 제대로 되는 것 같습니다(다만, 스레드에서 제목이 생략되는 이유는 모르겠고, 또한 내가 보낸 답글을 스레드 내에서 인라인으로 보이도록 설정하는 방법도 잘 모르겠습니다):
그리고 Thunderbird가 동일한 스레드를 어떻게 표시하는지입니다(실제로 Thunderbird도 내 답글을 인라인으로 표시하지 않는다는 것을 깨달았습니다):
Gmail에서는 이렇게 보입니다:
헤더는 아래와 같습니다. 게시물 ID는 91부터 시작하므로, 게시물 1 == 게시물 ID 91입니다.
게시물/이메일 1
(첫 번째 이메일이므로 References나 In-Reply-To가 없습니다)
From: Martin Brennan via The Email Threading Sandbox <notifications@cdckmartintesting.discoursemail.com>
Reply-To: The Email Threading Sandbox <incoming+3706c086cd36c6e37550c24f4e25c9b8@cdckmartintesting.discoursemail.com>
To: imaptest2@discourse.org
Message-ID: <discourse/post/91@discoursehosted.martin-brennan.com>
Subject: [The Email Threading Sandbox] [Royal Court] Threading topic 1 for
게시물/이메일 2
From: Bizarro Martin via The Email Threading Sandbox <notifications@cdckmartintesting.discoursemail.com>
Reply-To: The Email Threading Sandbox <incoming+9ea955b74a04dc85f5504ad245636824@cdckmartintesting.discoursemail.com>
To: imaptest2@discourse.org
Message-ID: <discourse/post/92@discoursehosted.martin-brennan.com>
In-Reply-To: <discourse/post/91@discoursehosted.martin-brennan.com>
References: <discourse/post/91@discoursehosted.martin-brennan.com>
Subject: [The Email Threading Sandbox] [Royal Court] Threading topic 1 for
게시물/이메일 3
From: Martin Brennan via The Email Threading Sandbox <notifications@cdckmartintesting.discoursemail.com>
Reply-To: The Email Threading Sandbox <incoming+410877b7f868b59945f3e3ea16570fc4@cdckmartintesting.discoursemail.com>
To: imaptest2@discourse.org
Message-ID: <discourse/post/93@discoursehosted.martin-brennan.com>
In-Reply-To: <discourse/post/91@discoursehosted.martin-brennan.com>
References: <discourse/post/91@discoursehosted.martin-brennan.com>
게시물/이메일 4
게시물 2 그리고 게시물 3에 대한 답글이지만, 하나만 선택해야 하므로 References 체인의 부모로 게시물 3을 사용합니다.
Date: Mon, 22 Aug 2022 04:05:45 +0000
From: Bizarro Martin via The Email Threading Sandbox <notifications@cdckmartintesting.discoursemail.com>
Reply-To: The Email Threading Sandbox <incoming+0a63eba3765f58e709a2ca538ca2b926@cdckmartintesting.discoursemail.com>
To: imaptest2@discourse.org
Message-ID: <discourse/post/94@discoursehosted.martin-brennan.com>
In-Reply-To: <discourse/post/93@discoursehosted.martin-brennan.com>
References: <discourse/post/91@discoursehosted.martin-brennan.com>
<discourse/post/93@discoursehosted.martin-brennan.com>
Subject: [The Email Threading Sandbox] [Royal Court] Threading topic 1 for
게시물/이메일 5
이것은 게시물 4에 직접 답하는 것이며, 게시물 4는 다시 게시물 3에 직접 답합니다.
Date: Mon, 22 Aug 2022 05:05:06 +0000
From: Martin Brennan via The Email Threading Sandbox <notifications@cdckmartintesting.discoursemail.com>
Reply-To: The Email Threading Sandbox <incoming+d66f675a0ce64fcaa2ba6b91e3112b05@cdckmartintesting.discoursemail.com>
To: imaptest2@discourse.org
Message-ID: <discourse/post/95@discoursehosted.martin-brennan.com>
In-Reply-To: <discourse/post/94@discoursehosted.martin-brennan.com>
References: <discourse/post/91@discoursehosted.martin-brennan.com>
<discourse/post/93@discoursehosted.martin-brennan.com>
<discourse/post/94@discoursehosted.martin-brennan.com>
Subject: [The Email Threading Sandbox] [Royal Court] Threading topic 1 for
게시물/이메일 6
이메일로 보낸 내 답글에 대한 답글입니다. Thunderbird가 생성한 (이상한) Message-ID 12d1ec8f-859c-2339-2c7d-9cb3310756a2@discourse.org를 유지했다는 점에 유의하세요.
Date: Mon, 22 Aug 2022 05:16:31 +0000
From: Martin Brennan via The Email Threading Sandbox <notifications@cdckmartintesting.discoursemail.com>
Reply-To: The Email Threading Sandbox <incoming+fb424977c7bd0c8146bdd7302dc35933@cdckmartintesting.discoursemail.com>
To: imaptest2@discourse.org
Message-ID: <discourse/post/97@discoursehosted.martin-brennan.com>
In-Reply-To: <12d1ec8f-859c-2339-2c7d-9cb3310756a2@discourse.org>
References: <discourse/post/91@discoursehosted.martin-brennan.com>
<discourse/post/93@discoursehosted.martin-brennan.com>
<discourse/post/94@discoursehosted.martin-brennan.com>
<discourse/post/95@discoursehosted.martin-brennan.com>
<12d1ec8f-859c-2339-2c7d-9cb3310756a2@discourse.org>
Subject: [The Email Threading Sandbox] [Royal Court] Threading topic 1 for
2022-08-22
지금 DM을 보내서 제 테스트 사이트에서 계정을 설정해 드리고, 이메일을 주고받으며 이것이 기대하시는 것과 일치하는지 확인해 볼 수 있을까요?
6개의 좋아요
2022년 8월 22일 05:36, Martin Brennan가 Discourse Meta를 통해:
@cameron-simpson 설명하신 대로 작동하도록 설정한 것 같습니다.
mutt를 설정해 두었고, 스레딩이 정상적으로 이루어지는 것 같습니다(다만 스레드에서 제목이 생략되는 이유와, 내 보낸 답글을 스레드 안에서 인라인으로 보기 위해 어떻게 설정해야 하는지는 잘 모르겠습니다):
제 눈에는 잘 보입니다.
답글에서는 제목이 생략됩니다(제목이 변경되지 않는 한). 이렇게 하면 다음 스레드가 어디에서 시작되는지 보기 쉬워집니다. 원하신다면 스레드를 접어 두실 수도 있습니다.
자신의 답글을 보려면 해당 폴더에 답글 사본이 있어야 합니다. $record 설정이 이를 제어합니다.
그리고 Thunderbird가 동일한 스레드를 어떻게 표시하는지 아래에 있습니다(실제로 Thunderbird도 내 답글을 인라인으로 표시하지 않는다는 걸 깨달았습니다):
이것도 제 눈에는 잘 보입니다.
Gmail에서는 이렇게 보입니다:
이건… 꽤 비축약적이네요 
헤더는 아래에 있으며, 게시물 ID는
91부터 시작하므로 게시물 1 == 게시물 ID 91입니다.
[…]
메시지 관계에 대한 설명에 따르면 이 헤더들은 모두 올바르게 보입니다.
Discourse가 Reply-To에 고유한 ID를 사용하고 있다는 것을 알 수 있습니다. 이는 아마도 대상 이메일 주소 기반으로 이메일 답글을 연결하기 위한 것일 것입니다. 분명히 이 방식은 작동합니다. 만약 Discourse가 답글의 In-Reply-To 헤더에서 이를 파생했다면, 더 안정적인 주소를 사용할 수 있었을 것입니다
지금 PM을 보내서 테스트 사이트 계정을 설정해 드리고, 서로 이메일을 주고받으며 이것이 기대하시는 것과 일치하는지 확인해 볼 수 있을까요?
물론입니다!
감사합니다,
Cameron Simpson cs@cskk.id.au
2개의 좋아요
실제로 이것은 우리가 카테고리로 보내는지 토픽으로 보내는지 결정하는 데 사용되며, In-Reply-To나 References에 사용되는 메시지 ID만큼 많이 사용되지는 않습니다.
감사합니다. 개인 메시지와 제 사이트에서 이메일 초대장을 보내겠습니다.
지금까지 상당한 논의가 오갔고, 예상대로 작동하는 것 같습니다. Thunderbird에서 해당 스레드의 예시는 다음과 같습니다:
@cameron-simpson 이 기능을 이제 Discourse 코어에 포함해도 될까요? 테스트를 도와주셔서 다시 한번 감사합니다.
1개의 좋아요
References 부분을 좀 더 자세히 검토해 봐야 할 것 같아요. 어떤 메시지 안에서 뭔가 이상한 점을 본 것 같거든요. 이메일로 다중 답변(multireply)을 보냈는데, 그렇게 인식되지 않는 것 같더라고요. 오늘 밤에 한번 확인해 볼게요.
1개의 좋아요
아, 네. 방금 작성하신 최신 게시글을 확인했습니다. Discourse에서 두 개의 게시글에 답글을 작성할 때 어떤 동작을 기대하고 계신가요? 수신된 이메일에서 인용문을 파싱하여 여러 게시글에 대한 답글로 속성을 부여하는 기능을 지원할지 확신하지 못하겠습니다. References도 추가로 확인해 주셔서 감사합니다. 만약 직접 Discourse 인스턴스를 가지고 계셨다면 이 기능을 테스트해 보거나, 아니면 로직이 궁금하셨다면 해당 코드가 있는 브랜치 feature/the-phantom-email-thread를 참고해 보실 수 있습니다. 링크는 FEATURE: Overhaul email threading - Pull Request #17996 - discourse/discourse - GitHub 입니다. 이 브랜치도 아직 조금 더 정리할 부분이 있습니다.
수정: 답글 문제를 찾아서 테스트 포럼에서 답변했습니다.
1개의 좋아요
Martin Brennan이 Discourse Meta를 통해 2022년 8월 23일 06:16에 작성:
아, 방금 작성하신 최신 게시물을 이제 확인했습니다. 두 개의 게시물에 답글을 작성할 때 Discourse에서 어떤 동작을 기대하시나요? 이메일로 들어온 답글에 대해 인용문을 파싱하여 여러 게시물에 속성을 부여하는 기능을 지원하지 않는 것 같습니다.
그렇게 기대하지는 않았습니다. Discourse가 In-Reply-To 메시지 ID를 확인하고, 해당 ID가 일치하는 게시물과 연관 지어, 이를 바탕으로 "여러 답글(multiple reply)"을 유도해 주기를 기대했습니다.
그럼에도 불구하고, 웹에서 다중 답글을 작성하는 방법조차 모릅니다(이메일에서는 적어도 mutt를 사용하면 꽤 쉽습니다). 또한 데이터베이스에서 부모 게시물을 어떻게 표현하는지도 알지 못합니다. 메시지 텍스트 자체를 파싱하지는 않겠죠?
References헤더에 대해서도 더 자세히 살펴봐 주셔서 감사합니다. 만약 여러분이 자신의 Discourse 인스턴스를 가지고 있고 이를 테스트하거나, 이 브랜치에 포함된 코드의 로직이 궁금하다면
feature/the-phantom-email-thread를 참고하십시오:
FEATURE: Overhaul email threading - Pull Request #17996 - discourse/discourse - GitHub . 이 코드도 조금 더 정리해야 합니다.
감사합니다, 확인해 보겠습니다. 우리의 테스트 토론 구조를 그림으로 그려 보고, 다양한 헤더를 그것과 대조해 봐야 합니다. 오늘은 너무 산만했습니다.
감사합니다,
Cameron Simpson cs@cskk.id.au
여러 곳에 코멘트를 달아 두었는데, 머리가 잘 돌아가지 않는 상태입니다. 특히 add_identification_field_headers에 달린 코멘트는 오히려 오해에서 비롯된 것일 수 있습니다. 이 새로운 실험적 모드가 활성화되지 않았을 때의 폴백/원래 코드인가요? add_experimental_identification_field_headers에 달린 코멘트들이 더 중요한 부분인 것 같습니다.
1개의 좋아요