최근 몇 달간 다양한 Discourse 그룹에서 수신 이메일 파싱(imbound email parsing) 개선에 대한 여러 요청이 있었습니다. 사용자 스토리로 표현하면, 이러한 요청은 크게 다음과 같이 분류할 수 있습니다:
- “웹사이트에 게시할 때 사용할 수 있는 동일한 HTML 기능을 이메일로 답글을 보낼 때도 사용할 수 있기를 바랍니다.”
- “우편 목록(mailing list)의 메시지를 보고 검색할 수 있는 기능을 원합니다.”
- “이메일로 생성된 콘텐츠(답글을 통한 이메일 및 일괄 가져오기를 통한 것 모두)가 일관되게 깔끔하게 포맷되고 정확하게 파싱되기를 바랍니다.”
아래에서 이러한 요청의 실제 사례 링크를 제공하겠지만, 당장은 이해해야 할 중요한 점은 이 세 가지 “다르” 보이는 요청이 실제로는 동일한 근본적인 것, 즉 더 정확한 수신 이메일 파싱을 요구하고 있다는 것입니다.
몇 달 전 저는 @sam에게 우리 회사가 제공하는 상업용 이메일 파싱 API를 Discourse에서 사용할 수 있도록 활성화하는 것에 대해 이메일을 보낸 적이 있습니다. Sam은 Discourse의 기존 수신 이메일 파싱 솔루션보다 우리 API를 통합할 때 얻을 수 있는 이점을 설명하고, 또한 우리 API를 플러그인으로 통합하는 방법에 대해 설명하는 탐색적 게시물을 여기에 작성하는 것을 제안했습니다.
저는 이 두 가지 주제를 자세히 다루되, Discourse의 현재 이메일 파싱 솔루션의 상태부터 시작하겠습니다. 그리고 지난 몇 년간 이메일 파싱에 대해 고민해 보지 않은 분들을 위해, 이 문제에 대한 배경 지식도 함께 제공하겠습니다.
이 게시물은 꽤 길지만, 자유롭게 건너뛰어 읽으셔도 됩니다. 다룰 내용은 다음과 같습니다:
- Discourse의 현재 이메일 파싱 상태
- 더 나은 이메일 파싱의 이점
- 이해관계자 사용자 페르소나
- FWD:Everyone 이메일 파싱 API
A. 서명 및 답글 제거
B. HTML 마크업 정규화
C. 언어 지원
D. CSS를 통한 스타일링 - 제안된 통합 방안
- API 테스트
Discourse의 현재 이메일 파싱 상태
Discourse에는 이미 이메일로 답글을 보내는 기능이 있어, 사용자의 이메일 답글을 특정 토픽 내의 새로운 포럼 게시물로 변환합니다. 이 기능은 다음과 같이 작동합니다:
- 사용자가 구독 중인 포럼 토픽에 새 게시물이 있다는 이메일 알림을 받습니다.
- 사용자는 이 이메일에 답글을 보냅니다.
- 이 이메일 답글은 관련 포럼 토픽의 새 게시글로 변환됩니다.
개념적으로 이는 무가치한 기능이며, 많은 사람들에게 선호되는 워크플로우이고, Discourse로 이주를 고려 중인 많은 우편 목록 기반 커뮤니티에게는 필수적입니다.
그런데 문제는 이러한 이메일 답글이 포럼 게시물로 변환될 때, 종종 포맷이 누락되거나 잘못되거나, 심지어 텍스트가 누락된 상태로 렌더링된다는 것입니다. 이는 아래에서 자세히 살펴볼 이유들이 있어 매우 심각한 문제입니다.
흔한 문제에는 다음이 포함됩니다:
- 불릿 포인트가 올바르게 렌더링되지 않음
- 텍스트 사이의 줄바꿈 누락
- 텍스트 사이의 불필요한 줄바꿈
- 사용자가 작성한 텍스트가 완전히 삭제됨
이러한 문제가 흔하다고 말할 때, 이는 외국어 이메일을 난해한 이메일 클라이언트로 보낼 때 가끔 발생하는 것을 의미하지 않습니다. 오히려 Gmail과 Outlook에서 영어로 기본적인 이메일 답글을 보낼 때 흔히 발생하는 것을 의미합니다.
다음은 이러한 문제에 대해 불만을 제기하는 사용자의 실제 사례 두 가지로, 모두 [Python-Dev] 우편 목록에서 가져온 것입니다:
https://www.prettyfwd.com/t/Wco-c1ZCR7mUwiww0j6s9w/#message-5
https://www.prettyfwd.com/t/Wco-c1ZCR7mUwiww0j6s9w/#message-36
(Prettyfwd는 FWD:Everyone 이메일 파싱 API를 사용합니다.)
저는 Discourse로 기존 우편 목록에서 콘텐츠를 가져오는 것을 시도해 보지는 않았지만, 경험에 비추어 볼 때 이메일로 답글을 보낼 때의 오류율이 무엇이든, 전체 이메일 스레드를 렌더링할 때의 오류율은 적어도 한 단계(10배) 이상 높을 것입니다. 이는 서명과 답글을 제거하고, 인라인 답글을 처리하며, 깊게 중첩된 마크업을 다루는 등의 복잡성이 증가하기 때문입니다.
실제 사례로, LLVM 재단 회장이자 Tanya Lattner가 작성한 이 Mailman에서 Discourse로의 이주 회고록은 기술적 우려 섹션에서 이러한 문제에 간접적으로 언급하고 있습니다:
질문을 해보니, 그들이 불만을 제기하는 구체적인 사항은 콘텐츠가 너무 일찍 잘리면서 누락되는 이메일의 비율이 높다는 것입니다. 지난 19년간의 우편 목록 아카이브에서 이루어진 기존 토론과 문서는 무가치하기 때문에, 이 문제가 완전히 해결될 때까지 Mailman을 종료할 수 없다고 느끼고 있습니다.
그렇다면 Discourse의 현재 이메일 파싱 상태가 "충분히 좋은"지 어떻게 알 수 있을까요? 저는 이를 3단계 리트머스 시험으로 제시하고 싶습니다:
- 사용자는 이메일로 답글을 보내는 기능을 사용할 경우, 웹 인터페이스를 통해 게시한 것과 똑같이 보일 정도로 콘텐츠가 정확하게 파싱된다는 것을 완전히 신뢰해야 합니다.
- 포럼 관리자는 이메일로 답글을 보내는 것을 허용하더라도, 이것이 추가적인 업무나 불만을 초래하지 않을 것이라고 신뢰해야 합니다.
- Discourse의 직원들은 이 기능을 1급 참여 방식으로 적극적으로 홍보할 수 있을 정도로 충분히 신뢰해야 합니다.
이러한 각 조건이 충족되고 있다고 확신할 수 없다면, 이메일로 답글을 보내는 기능이 존재하더라도 잠재적 이점의 대부분은 결코 실현되지 않을 것입니다.
현재 일어나고 있는 상황입니다.
즉, 기존 이메일 파싱 코드를 80-20 솔루션으로 characterize할 수 있지만, 80-20 솔루션이 실제로는 의미가 없는 맥락에서 그렇습니다. 문제는 예를 들어 80%의 이메일이 올바르게 파싱되더라도, 잠재적 이점의 10%조차 얻기 어렵다는 것입니다.
따라서 이메일로 답글을 보내는 것(및 일괄 이메일 가져오기)이 이미 존재함에도 불구하고, 사용자는 궁극적으로 원하는 경험을 얻지 못하고 있으며, 모더레이터와 직원에게는 추가적인 업무가 발생하고, 커뮤니티는 가치 있는 콘텐츠와 사용자 성장에서 손해를 보고 있습니다.
더 나은 이메일 파싱의 이점
소셜 소프트웨어는 인간의 필요를 충족시키는 정도만큼만 성공합니다.
사람들이 웹 포럼에 게시물을 올리는 이유는 다른 사람들과 지식을 공유하고 싶고, 그들의 의견을 영향력을 미치고 싶고, 일반적으로 지혜롭거나, 분야 전문성을 가진 사람으로, 또는 현실 세계에서 가치 있는 기여를 하는 사람으로 인식되고 싶기 때문 등입니다.
텍스트 기반 커뮤니케이션의 경우, 이러한 결과를 달성할 가능성은 무엇을 말하는가뿐만 아니라, 그것을 어떻게 타이포그래피로 표현하는가에 따라 달라집니다.
셰익스피어의 공백에 대한 책이 통째로 존재하는 이유입니다. 뉴욕 타임즈가 뉴욕 포스트보다 더 진지하게 받아들여지는 부분적인 이유이기도 합니다. 그리고 페이스북이 마이스페이스를 이긴 주요 이유이기도 합니다.[1]
사용자가 작성한 텍스트가 본인의 잘못 없이 엉망으로 포맷되면, 소셜 소프트웨어를 사용하게 하는 인간의 필요는 더 이상 충족되지 않습니다. 오히려 반대 상황이 발생하며, 사용자는 어리석어 보입니다.
이메일로 답글을 보내는 기능을 사용하지 않는 사람들조차, 토픽(및 더 큰 포럼)의 다른 게시물이 엉망으로 보이면 권위와 존경심을 잃게 됩니다.
이해관계자 사용자 페르소나
모두가 게시물이 일관되게 미적으로 매력적인 타이포그래피로 렌더링될 때 혜택을 보지만, 더 나은 수신 이메일 파싱에서 특히 혜택을 볼 수 있는 사용자 페르소나에는 다음이 포함됩니다:
- [Python-Dev]와 [Django-Dev]와 같은 우편 목록의 현재 멤버들로, Discourse의 이점을 완전히 이해하고 커뮤니티가 Discourse로 이전하는 것을 기뻐하지만, GNU Mailman, Google Groups 등과 구별되지 않는 방식으로 참여할 수 있는 경우에만 그렇습니다. 이 유형의 요청에 대한 실제 사례는 다음과 같습니다: https://www.prettyfwd.com/t/Wco-c1ZCR7mUwiww0j6s9w/#message-89
- 일반적으로 Discourse로 이주하는 것을 기꺼이 하겠지만, 수십 년간의 기존 콘텐츠가 동일한 플랫폼 내에서 쉽게 검색 가능하다면 훨씬 더 열정적으로 이주할 이메일 기반 커뮤니티의 멤버들.
- 간헐적으로 포럼을 확인하는 캐주얼 사용자. 예를 들어, Growing Fruit에서는 북미 파파야(pawpaw) 재배에 관한 모든 토픽에 이메일로 구독되어 있습니다. 여름과 가을에는 이 토픽들의 끊임없는 새 게시물 흐름을 읽기 위해 하루에 여러 번 해당 포럼을 방문하지만, 이 기간을 제외하면 주로 이메일 알림이 저를 참여하게 합니다.
- 웹을 간헐적으로만 사용하는 사람들. 사람들은 웹을 정기적으로 사용하지 않으면 디지털 격차와 관련이 있다고 가정하는 경우가 많지만, 항상 그런 것은 아닙니다. 자신의 분야에서 최상위에 위치하여 웹을 정기적으로 사용할 필요가 없는 상황에서 격리되어 있는, 매우 지적이고 기술적인 사람들이 많습니다. 실제 사례로는 현존하는 최고의 컴퓨터 과학자 중 한 명인 Donald Knuth가 웹을 정기적으로 사용하지 않는 것입니다. 모든 분야에 이러한 사람들이 있으며, 그들의 지식을 공유하게 하는 것은 무가치합니다. 제 경험에 따르면 이러한 사람들은 어떤 포럼의 정기적인 기여자가 될 가능성이 낮지만, 사람들이 논의하고 있는 그들이 관심 있는 토픽이 있다는 말을 들으면, 이메일로 구독하고 해당 특정 토픽에 기여하는 경우가 많습니다.
큰 그림으로는, 수신 이메일 파싱을 개선하는 것은 이미 정기적으로 활동적인 Discourse 기여자로부터의 참여를 증가시킬 뿐만 아니라, 그렇지 않으면 플랫폼으로 이주하고 싶었던 많은 커뮤니티의 장벽을 제거하고, 그렇지 않으면 기여하지 않았을 사람들에게서 매우 가치 있는 콘텐츠를 끌어내는 데 도움이 되어야 합니다.
FWD:Everyone 이메일 파싱 API
FWD:Everyone 이메일 파싱 API는 두 가지 일을 수행합니다:
- 각 이메일 메시지에서 서명과 답글을 정확하게 제거하되, 인용된 텍스트에 대한 인라인 답글은 허용합니다.
- 이메일 클라이언트가 생성하는 매우 복잡한 HTML 마크업을 가져와, 사용자 생성 콘텐츠 사이트에서 일반적으로 허용되는 약 12개의 HTML 태그로 정규화합니다 — 모든 과정에서 저자의 의도를 최대한 보존하면서요.
더 자세히 설명하겠지만, 먼저 실제 이메일 스레드를 보여주며 문제를 설명하는 제가 만든 비디오가 있습니다: https://www.youtube.com/watch?v=nPb3NQlz6V4
서명 및 답글 제거
FWD:Everyone 이메일 파싱 API는 평문과 HTML 이메일 모두에서 동일한 정확도로 작동합니다. API는 가능할 때 HTML 메시지 부분을 우선적으로 사용하는데, 그 이유는
- 저자가 선택하여 사용하는 HTML 포맷 기능(굵게, 기울임, 인용 블록, 코드 스니펫 등)은 텍스트 자체만큼이나 저자의 메시지의 필수적인 부분입니다.
- 이메일 클라이언트가 메시지의 HTML 버전을 평문 버전으로 변환할 때, 종종 이를 올바르게 수행하지 않습니다. 예를 들어, 이메일 클라이언트는 평문에서 불릿 목록과 같은 HTML 기능을 렌더링하려는 시도를 하지 않는 경우가 많으며, HTML 포맷 요소 내의 텍스트가 완전히 누락되는 경우도 흔합니다.
물론 일부 사용자는 평문 이메일을 보내는 것을 선호합니다. 이 때문에, 평문 전용 이메일도 서명과 답글이 동일한 정확도로 제거되어야 합니다.
FWD:Everyone 이메일 파싱 API는 이를 수행하며, 평문과 HTML 이메일 모두에서 인라인 답글을 올바르게 처리합니다.
정확성 측면에서, 서명과 답글을 제거할 때 이메일 파싱 라이브러리에서 발생할 수 있는 두 가지 유형의 오류가 있습니다:
- False positives(양성 오류) — 메시지에 포함되어야 할 텍스트가 잘못 제외되는 경우.
- False negatives(음성 오류) — 메시지에 포함되지 않아야 할 텍스트가 잘못 포함되는 경우.
다른 Discourse 커뮤니티(소문자 d)가 이메일을 사용하는 방식이 매우 다르기 때문에 정확한 정확도 통계를 제시하기는 어렵습니다. 하지만 Discourse의 현재 파싱 솔루션과 비교할 때, 현실적인 기대치는 다음과 같을 수 있습니다:
- 서명과 답글 제거 시 False positives 100배 감소
- 답글 제거 시 False negatives 10배 감소
- 서명 제거 시 False negatives 1~10배 감소 — 아마 더 나을 것이지만, 한 단계(10배)까지는 아닐 것입니다.
참고로, False positives는 일반적으로 사람이 쓴 것을 왜곡시키기 때문에 False negatives보다 훨씬 나쁩니다. 하지만 False negatives도 게시자(및 포럼의 모든 다른 사람들)를 최소한 전문적이지 않게 보이게 하고, 최악의 경우 완전히 어리석어 보이게 하므로 매우 나쁩니다.
FWD:Everyone이 취하는 접근 방식은 False positives를 유발할 수 있는 서명 제거 트릭을 완전히 배제하는 것입니다. 이로 인해 False negatives가 증가할 수 있지만, 이는 알고리즘이 모서리를 자를 필요가 없이 정당한 방식으로 작동하도록 막대한 노력을 기울임으로써 크게 상쇄됩니다.
FWD:Everyone 이메일 파싱 API가 일반적으로 Discourse의 현재 솔루션보다 훨씬 더 정확할 것이라는 큰 그림의 이유는, 우리의 API가 개별 이메일 답글 게시물보다 훨씬 더 어려운 문제인 전체 이메일 스레드를 파싱하도록 설계되었기 때문입니다. 그 결과,我们的产品은 Discourse의 필요와 기존 선행 연구에 비해 과도하게 엔지니어링되었습니다.
HTML 마크업 정규화
이메일로 제출된 답글(및 가져온 이메일 스레드)이 다른 사용자 생성 콘텐츠와 동일해 보이려면, 궁극적으로 사용자가 웹사이트를 통해 답글을 보낼 때 허용되는 동일한 HTML 부분 집합을 사용하여 렌더링되어야 합니다.
이는 놀라울 정도로 복잡합니다.
Gmail과 Outlook과 같은 이메일 클라이언트로 작성된 이메일은 약 50개의 HTML 태그, 약 25개의 HTML 속성, 약 175개의 CSS 스타일의 일부 조합으로 인코딩됩니다. 또한, 이 마크업은 종종 심하게 난독화됩니다. 텍스트 단락은 다음과 같이 보일 것이라고 기대할 수 있습니다:
<p>Some text!</p>
하지만 대신, 간단한 단락조차도 div, span, table, list 등의 깊게 중첩되고 전혀 합리적이지 않은 조합으로 인코딩되는 경우가 많습니다. 이는 답글 제거와 마크업 정규화 모두의 복잡성의 주요 원인입니다.
어쨌든, 파싱 후 각 메시지는 다음 마크업만 사용하여 렌더링됩니다:
허용된 블록 요소: <p>, <ul>, <ol>, <li>, <blockquote>, <pre>
허용된 인라인 요소: <code>, <a>, <b>, <i>, <u>, <s>, <span>
참고:
<a>태그를 제외한 유일한 허용 속성은'style'과'dir'입니다.- 유일한 허용 인라인 스타일은
'font-weight'입니다. <a>태그는'href','rel','title','target'속성을 가질 수도 있습니다.<span>요소는 font-weight가 올바르게 캐스케이드되도록 보장하기 위해 제한된 경우에만 사용됩니다. 따라서 항상 인라인'font-weight'와 함께 사용됩니다.- 향후,
<img>태그도 인라인 이미지를 표시하는 데 사용될 것입니다.
이 제한된 HTML 부분 집합으로 게시물을 렌더링하면, 이메일로 제출된 어떤 게시물도 웹 인터페이스를 통해 제출된 게시물과 동일한 타이포그래피를 사용하여 쉽게 렌더링할 수 있습니다.
이 모든 것은 저자의 의도를 최대한 보존하면서, 동시에 사용자가 단락 사이에 수십 개의 불필요한 줄바꿈을 추가하는 등의 일을 하지 못하도록 보장합니다.
또한 참조: 아래 ‘CSS 스타일링’ 섹션.
언어 지원
EmailReplyTrimmer는 현재 13개 언어에 대해 전체 또는 부분적인 지원을 제공합니다:
영어, 노르웨이어, 프랑스어, 독일어, 포르투갈어, 스페인어, 이탈리아어, 네덜란드어, 스웨덴어, 중국어, 러시아어, 폴란드어, 우크라이나어
반면, FWD:Everyone 이메일 파싱 API는 현재 30개 이상의 언어를 지원하며, Discourse가 현재 지원하는 모든 언어를 포함합니다:
영어, 스페인어, 포르투갈어, 카탈루냐어, 네덜란드어, 프랑스어, 독일어, 이탈리아어, 노르웨이어, 덴마크어, 스웨덴어, 핀란드어, 러시아어, 폴란드어, 우크라이나어, 터키어, 체코어, 루마니아어, 헝가리어, 히브리어, 아랍어, 페르시아어, 중국어, 일본어, 한국어, 힌디어, 인도네시아어, 태국어, 필리핀어, 아프리칸스어
FWD:Everyone 이메일 파싱 API는 RTL(우측에서 좌측으로) 언어를 완전히 지원합니다. 이는 아랍어와 같은 언어에서 텍스트가 올바르게 우측에서 좌측으로 흐를 뿐만 아니라, 불릿 포인트와 같은 기능이 페이지의 올바른 쪽에 렌더링되도록 HTML 마크업에 적절한 속성이 적용된다는 것을 의미합니다.
API는 사용되는 이메일 클라이언트에 따라 추가 언어에서도 작동할 수 있지만, 공식적으로 지원하는 언어 집합은 최소한 Gmail, Outlook, Apple Mail에서 작동하도록 테스트됩니다. 덜 인기 있는 이메일 클라이언트는 사용량이 가장 많은 언어에서 명시적으로 테스트됩니다. 그리고 API는 공개 우편 목록에서 수천 개의 이메일 스레드에 대해 테스트되므로, 출처가 불분명한 실제 세계의 이상한 동작에 대한 수많은 수정 사항이 있습니다.
참고로, 다양한 언어를 지원하는 것은 해당 언어로 텍스트를 표시하는 것 이상으로 중요합니다. 영어로 텍스트를 작성하지만, 이메일 클라이언트가 예를 들어 히브리어를 사용하도록 설정되어 있는 경우가 매우 흔합니다. 따라서 이러한 경우, 영어 답글을 올바르게 파싱하려면 히브리어를 완전히 지원하는 것뿐만 아니라, 더 일반적으로 RTL 언어를 지원하는 것도 필요합니다.
다양한 언어 계열의 언어를 지원하는 것은 또한 unicode가 올바르게 처리되고 저장되도록 보장하는 데 도움이 되며, 이는 더 많은 비서구 언어에 대한 지원이 추가될 때 미래에 문제를 일으킬 수 있는 방식이 아닌 것을 의미합니다.
CSS 스타일링
위에서 언급했듯이, 우리 API의 주요 강점 중 하나는 HTML 마크업을 신중하고 논리적인 방식으로 정규화하는 능력입니다. 이 정규화 과정은 텍스트의 가독성과 접근성을 최적화하도록 설계되었으며, 동시에 원래 저자의 의도를 최대한 보존합니다.
따라서 모든 텍스트는 인라인 또는 블록 요소 내에서만 나타나고(떠다니는 텍스트는 없음), 모든 인라인 요소는 블록 요소 내에서만 나타납니다. 이는 텍스트를 스타일링하는 것이 쉽도록 하며, 예를 들어 서로 다른 요소 사이에 올바른 양의 공백이 있는지 보장하는 것입니다.
이것이 왜 가치 있는지에 대한 예시로, 이메일 클라이언트는 사용자가 텍스트 줄 바로 앞이나 뒤에 줄바꿈 없이 불릿 목록을 삽입하는 것과 같은 어리석은 일을 할 수 있도록 허용합니다. 그렇게 할 때 이메일 클라이언트가 생성하는 (극도로 단순화된) 코드는 다음과 같이 보일 수 있습니다:
<div>
Some text
<div> </div>
<span> • A bullet point</span>
<div> </div>
Some more text
</div>
FWD:Everyone 이메일 파싱 API는 위의 마크업을 다음과 같이 정규화합니다:
<p>Some text</p>
<ul>
<li>A bullet point</li>
</ul>
<p>Some more text</p>
이 정규화된 마크업은 이해하고 스타일링하기가 쉽고, 시각적으로 이제 불릿 목록 앞뒤에 줄바꿈도 있습니다. 이러한 종류의 사용자 편의성은 저자의 의도를 보존하면서 텍스트를 더 아름답고 읽기 쉽게 만듭니다. 이러한 사용자 편의성은 이메일로 제출된 훌륭한 콘텐츠가 일관되게 사회적 지위를 부여하도록 보장하며, 그것을 훼손하지 않습니다.
우리 API가 생성하는 단순화되고 정규화된 마크업은 또한 텍스트를 스타일링하는 방법에 대해 생각할 때, 디자이너와 개발자가 원래 이메일이 어떻게 포맷되었는지 대신 API가 허용하는 출력을 생각하기만 하면 된다는 것을 보장합니다. 그리고 API에서 허용되는 출력은 Discourse 웹 클라이언트가 허용하는 것과 거의 동일하므로, 이는 드롭-인 솔루션에 가까울 것입니다.
제안된 통합 방안
이메일로 답글을 보내는 기능은 플러그인으로 Discourse에 통합될 수 있으며, 이는 호스팅된 모든 Discourse 인스턴스에서 기본적으로 활성화될 수 있습니다.
기존 이메일 파싱 코드는 이 플러그인이 활성화되지 않은 Discourse 인스턴스에 사용됩니다.
추가로, FWD:Everyone 이메일 파싱 API가 일시적으로 사용 불가능한 경우, 수신되는 모든 메시지는 기존 이메일 파싱 코드를 사용하여 처리됩니다. 그런 다음 API가 다시 온라인이 되면, 게시 후 웹 인터페이스를 통해 편집되지 않은 메시지는 API에 의해 다시 처리될 수 있습니다.
플러그인은 자체 호스팅 Discourse 인스턴스에서도 선택적으로 활성화되도록 제공될 수 있습니다.
기존 우편 목록에서 Discourse로 이주하는 그룹의 경우, 우편 목록의 각 이메일 스레드도 API를 통해 파싱될 수 있지만, 이는 플러그인을 통해 수행되는 대신 Discourse의 기존 이주 스크립트와 프로세스에 통합될 가능성이 높습니다.[2]
API 테스트
API는 인증되지 않은 사용자에게 매우 낮은 레이트 리미트가 있지만, 누구나 테스트할 수 있도록 완전히 제공되고 있습니다.
Gmail 계정이 있는 경우, API를 테스트하는 가장 쉬운 방법은 다음과 같습니다:
- https://www.prettyfwd.com에 가서 G Suite 추가 기능을 설치합니다.
- https://api-demo.fwdeveryone.com에 가서 클라이언트 측 OAuth를 사용하여 API를 만져봅니다.
이 두 가지 웹 기반 도구와 실제 API 사이의 주요 차이는 전자(웹 도구)가 다음과 같다는 것입니다:
- HTML 테이블을 사용하여 스타일링된 메시지를 포함하는 스레드를 처리하지 않습니다.
- 스레드의 첫 번째 메시지에서는 답글을 제거하지 않습니다. (예: 스레드에 100개 이상의 메시지가 있어 Gmail이 여러 스레드로 분할하는 경우.)
API를 코드를 통해 직접 테스트하려면, Python과 Ruby 모두에 대한 시작 스크립트가 있습니다:
그리고 여기 관련 문서가 있으며, 알려진 문제와 제품 로드맵이 포함되어 있습니다:
[1] Viewing American class divisions through Facebook and MySpace.
[2] 기존 우편 목록에서 콘텐츠를 일괄 가져올 때, 올바르게 파싱되고 있는지 확인하기 위해 몇 개의 스레드에 대한 빠른 무결성 검사를 먼저 수행하는 것이 가치가 있습니다. 일부 그룹은 그대로 거의 완벽한 정확도로 파싱되지만, 다른 그룹은 사전 작업 몇 시간에서 큰 이점을 얻을 수 있습니다. 예를 들어, 일부 우편 목록 소프트웨어는 각 메시지의 하단에 추가된 텍스트를 제거하기 위해 각 목록에 대해 약간 커스텀 코드를 필요로 하는 반면, 다른 우편 목록 소프트웨어에서는 해당 플랫폼에 호스팅되는 모든 목록에 작동하는 예측 가능한 방식으로 이를 수행할 수 있습니다. 이러한 잠재적 문제 때문에, 일괄 가져오기 프로세스는 플러그인을 통해 수행되는 대신 감독된 이주의 일부로 실행되는 것이 좋습니다.