파일 로드 방식 변경?

[saschanaz]

Xeit는 페이지에 자바스크립트를 추가 로드하는 방식으로 이루어져 있으나, 장기적으로는 다른 방법을 쓸 수 있지 않은가 생각합니다.

우선 모바일 브라우저들은 지금처럼 즐겨찾기에 스크립트를 등록하여 사용하기가 어려운 것이 한 이슈입니다. 스크립트 등록도 안 될 뿐더러, 스크립트를 등록했다 하더라도 페이지에 로드되지 않는 것으로 알고 있습니다. (안드로이드 파이어폭스는 등록 및 로드 모두 작동합니다만 모바일 크롬, 모바일 IE는 작동하지 않습니다.)

또한 데스크탑 IE의 경우 페이지 내에 있는 메타 코드 때문에 구형 엔진을 불러오게 되어, Xeit가 작동하기 어려운 상황에 놓이기도 합니다. 예를 들어 우리은행의 경우 강제로 IE 7 엔진으로 로드하게 설정되어 있어 이 상태에서 Xeit를 불러와도 오류가 발생하며 작동하지 않습니다.

따라서, 지금처럼 이미 로드된 페이지에 자바스크립트를 덧입혀 작동시키는 것보다는 좀더 깔끔하게 별도의 페이지에서 파일을 파싱하여 작동시키는 것은 어떨까 생각합니다. 이 방법은 위에서 말한 즐겨찾기에 스크립트를 등록하여 사용하기 어려운 경우 및 최신 IE의 경우 모두 정상적인 작동이 가능할 것입니다.

장기적으로는 방식을 변경하는 것이 태블릿에서도 작동하는 등 모든 환경을 폭넓게 지원할 수 있다고 생각하여 이렇게 제안해봅니다. 감사합니다.

[tomyun]

사실 Xeit를 처음 만들 때 많은 고민을 하였고, 지금도 계속 고민하는 부분이었는데 잘 정리해주셨네요^^;

독립적인 사이트를 만들어놓고 그쪽에서 불러오게 하면 개발도 더 용이하고 이후에 확장하기도 편리할 것 같았습니다만, 오히려 신뢰성에 문제가 생기지 않을까 생각했습니다. 잘 알지 못하는, 처음 보는 사이트로 메일이 전송되는 것에 대해 반감을 가지는 분들이 분명히 계실 듯 하거든요. 그래서 첨부파일을 열어놓은 페이지에서 데이터를 내보내지 않고 모든 것을 처리할 수 있도록 꼼수를 써서 만든 것이 최초 버전이었습니다.

이후에 일부 메일의 성능 문제 때문에 알고리즘 로직들을 Web Worker 기반으로 분리(#17)하는 구조 변경이 있었는데요. 이때부터 로컬 파일에 대한 same origin policy 이슈 때문에 모바일 사파리 등에서 일부(대다수;) 메일 서비스를 통한 Xeit의 이용이 불가능한 상황이 되어 버렸습니다.

그래서 이런 부분을 어떻게 해결할까 다시 고민중이었는데요. 말씀하신 것처럼 독립적인 페이지를 구축해서 서비스를 하는 것이 최선일 것 같다는 생각이 듭니다. 원래 Xeit 자체도 더 큰 서비스의 로드맵 중 일부로 만들어본 것이기 때문에 장기적으로는 시도해보고 싶은 일이기도 하였구요.

일단 눈 앞의 이슈들이 어느 정도 정리되고 나면 구조를 잘 잡아서 바꿔나가보도록 하겠습니다^^ 조언 감사드립니다.

[saschanaz]

컨셉만 간단히 만들어보았는데 도움이 될지 모르겠습니다. @.@
http://jsfiddle.net/ASgbS/6/

페이지를 받아 메타 태그를 없애고 스크립트를 집어넣고 팝업으로 띄우는 방식으로, IE 최신 버전에서도 문제 없이 작동하며 모바일 브라우저에서도 즐겨찾기를 이용하지 않으므로 쉽게 사용 가능합니다. 다만 페이지 내에서 스크립트가 또 작동하여 페이지가 깨지는 문제가 있어 대충 타이머를 넣는 꼼수를 넣었는데 컨셉만 잡으려 만들었으니 필요하다면 나중에 해결할 수 있을 듯합니다.

사실 어차피 지금 상태에서도 외부 스크립트를 불러오는 것은 마찬가지니, 데이터가 로컬에서 연산된다는 것만 제대로 지켜주면 괜찮지 않을까 싶습니다.

[tomyun]

오~ 이렇게 하면 다운로드해 놓은 HTML 파일을 끌어다 놓으면 바로 열리게 Drag & Drop API도 적용해볼 수 있겠네요! 그런데 FileReader는 로컬 파일(file://)만 열 수 있는 것 맞나요? 네이버나 다음 메일 같은 곳에서 첨부파일 미리보기를 하면 HTML 파일을 다운로드하지 않고 http:// URL 그대로 열 수가 있는데 이러한 경우에도 적용이 가능할지 모르겠네요. 일단 File API 공부도 해볼겸 테스트해봐야겠어요~

[saschanaz]

http://jsfiddle.net/ASgbS/11/
한번 URL도 받도록 만들어봤는데... 로컬에서 갖고 놀면 잘 작동하긴 합니다만 웹에 적용하면 CORS에 걸리네요.. 음...

[saschanaz]

http://jsfiddle.net/ASgbS/15/
왠지 자꾸 하고 싶어서 타이머 꼼수 없이 바로 제대로 작동하도록 수정해 봤습니다. 이렇게 하면 지금 상태를 유지하고서도 다른 방식을 쓸 수 있겠네요!

안드로이드 돌핀 브라우저, 오페라 모바일 클래식에서 Xeit가 쾌적한 속도로 제대로 작동하고 안드로이드 크롬, 오페라 15에서는 input 엘리먼트에서 HTML 파일을 불러오지 못하는 문제가 있지만 URL로 불러오면 제대로 작동하긴 하는데 꽤 느리네요. 기본 브라우저에서는 파일은 불러오는데 너무 느리고, 파이어폭스도 마찬가지네요 @.@

WP8 모바일 IE에선 뭐가 문제인지 제대로 안 되는 것 같네요. ㅠㅠ

[saschanaz]

개인적으로 태블릿에서 쓰기 위해 좀 더 다듬어서 만들어 보았습니다. http://saschanaz.github.io/xeit/xeit.html
페이지 내에서 드래그 앤 드랍 및 클릭해서 열기를 지원하고 있습니다.
IE10/11, 파폭, 오페라, 크롬에서 테스트했습니다.

[tomyun]

오! 드래그 앤 드랍 꼭 해보고 싶었는데 멋지게 만들어주셨네요! 작업해주신 것처럼 도움말쪽에 이렇게 들어 있으면 직접 페이지 들어오시는 분들은 훨씬 편하게 사용하실 수 있겠어요.

그러고보니 제가 이해가 부족했던 것 같아요. 기본적으로 로컬에 다운로드되어 있는 보안메일을 태블릿 등에서 열기 위한 목적으로 작업을 하신거죠? 일단 브라우저에서 Xeit를 띄우고, 거기에서 파일을 불러오는 식으로요. 그런데 만약 브라우저에 로컬이나 웹상의 보안메일이 열려 있는 상태에서는 FileReader나 XMLHttpRequest로 접근이 어려우니 이 방법을 적용하기는 어려운 것이고요. 저는 제안해주신 방식이 기존 방식을 완전히 대체할 수 있는지 계속 고민했었거든요^^;

사실 처음에 고려했던 주 사용 시나리오는 (원래의 ActiveX 플러그인처럼) 명세서 HTML을 브라우저로 띄운 상태에서 최소한의 조작(북마클릿 혹은 크롬 확장)으로 열어보는 것이었습니다. 이런 루트에 대하여 현재처럼 DOM을 조작하여 Xeit 코드를 끼워넣거나(보안메일 상위), 외부 서버로 메일을 보내서(Xeit 상위) 해독하는 방법 사이에 저울질을 했었지요. 전자는 보안메일이 로컬에 있는 경우(file://) 브라우저나 OS의 보안정책에 따라 구동이 안 되는 경우들이 있어 골치가 아프고, 후자로 가면 외부 전송에 대한 거부감/신뢰성 이슈가 따라다니겠지요.

아마 100% 완전한 해결책은 찾기 힘든 것 같고, 각 상황에 맞춰 최대한 편리한 방법을 제공해주는 것이 중요할 듯 한데요. Xeit 페이지에 직접 들어와서 사용하시는 분들에게는 이번에 구현해주신 방식이 최적일 것 같아요. 기존 방식과는 별개로 추가되는 사항이니 특별히 충돌하는 부분도 없을 것 같구요~

[saschanaz]

감사합니다 :D 그러면 일단 이 상태로 Pull request 해 보도록 하겠습니다. 문구는 대충 끼워맞췄는데 수정이 필요할까 싶네요...

말씀해주신 '열려 있는 상태에서' 조작을 최소한으로 하는 해법은 지금으로선 결국 플러그인밖에 없지 않나 싶어요. 현재 쓰고 있는 DOM 조작도 완전 자동이 아닌 한 번 정도 사용자의 조작이 필요한 부분이고요. 다만 크롬 웹앺은 보안 설정을 하나 풀어 주어야 한다는 점에서 좀 거부감이 드는 부분이 있고 또한 모바일에선 사용하기 힘든 점이라는 것이 걸리네요. 외부 서버로 메일을 보낸다는 것도 결국 사용자가 어떤 페이지를 열어야 한다는 것인데 그 방법에 어떤 장점이 있나요?

로컬 파일 자체를 불러들이려고 시도한 것의 배경에는 제가 IE를 쓰는 것도 있었지만 다른 이슈도 있었습니다. SKT 보안 메일의 경우 파이어폭스나 크롬도 지원해 이 브라우저들로 접속하면 플러그인 다운로드 페이지를 띄우는데, 파이어폭스는 상관 없지만 크롬은 파일을 자동으로 다운로드하는 성질이 있다 보니 보안 메일을 직접 열 때마다 플러그인 설치 파일이 자동으로 다운로드되더군요. =_=;;

그런 뜻에서 이런 방법을 택했습니다만 역시 따로 페이지에 접속해야 한다는 부분이 있으니, 최적의 방법은 앞으로도 계속 고민을 해 봐야 할 것 같습니다.

[tomyun]

1. 크롬 확장에서 로컬 보안메일을 열기위해서는 보안 설정을 풀어줘야 하지만, 다음 같은 일부 웹 메일 서비스에서는 미리보기 기능으로 다운로드 없이 웹상에서 그대로 볼 수 있기도 합니다~
2. 외부 서버를 계속 고민했던 것은 iOS의 모바일 사파리(아마 안드로이드 크롬도?)에서 로컬 파일에 대한 작동이 되지 않기 때문이었습니다. 브라우저 주소창의 URL은 file://이 아닌 http://로 보이지만 실제 다운로드를 시키는 네이버 메일에서는 작동이 안 되고, 미리보기를 하는 다음 메일에서는 작동이 되는 식이죠. 내부적으로는 document.domain의 설정 유무에 따른 same-origin policy 이슈로 외부 js 파일에 접근하지 못하는 것이 원인입니다. 이걸 우회해보려고 이런저런 고민을 해봤는데 결국에는 Xeit 초기 버전처럼 Web Worker 없이 통짜 js를 만드는 방법 밖에는 없지 않을까 싶더라구요. 오히려 예전에는 되던 것이 최신 버전에서는 regression 처럼 되어 있어 계속 마음에 걸리네요=_=
3. 저도 SKT 보안메일을 열어보니 자꾸 맥용 플러그인을 다운로드하려고 해서 귀찮더라구요. 사파리는 자동 다운로드가 기본이기는 한데, 크롬은 일단 아래쪽에 확인창이 떠서 discard 해주면 크게 불편하지는 않던데요^^; 아마 설정에 따라 다른가봅니다.

아무튼 이와 별개로 이번에 만들어주신 파일 업로드 방식은 굉장히 유용할 것 같네요. 잘 정리해서 merge해보겠습니다. 감사합니다!

[saschanaz]

1. 안드로이드 크롬은 아쉽게도 즐겨찾기를 통한 DOM 조작이 가능하지 않습니다. 누르면 새 페이지를 띄워 버리더군요. 음... 스크립트 파일에 대해서는 브라우저마다 same-origin policy가 조금씩 다르더군요. 보통은 스크립트에 대해서만 예외로 쳐 준다고 들었는데, 아마 호환성 문제 때문이 아닌가 싶습니다. 사파리에서의 문제가 외부 스크립트 파일에 접근하지 못하는 것이 원인이라면 Cross-Origin Resource Sharing에 따라 서버에서 response에 Access-Control-Allow-Origin: * 헤더를 넣어 주면 아마 클라이언트에서 거부 없이 받아들일 것입니다. 이걸로 해결 가능하다면 외부 서버로 메일 파일을 업로드하지 않아도 될 테지만, 제가 알기론 GitHub Pages에서는 헤더 설정을 지원하지 않으니 외부 서버 자체는 필요하겠네요.
2. 그런가요? 전 확인 없이 바로 다운로드하더군요... 새 오페라도 그렇고 ㅠㅠ. 한 번 설정을 뒤져봐야겠습니다.

높이 평가해 주셔서 감사합니다. Xeit가 계속 발전하면 좋겠습니다. 누가 Xeit의 진가를 알아줘서 보안 메일에 Xeit가 기본으로 들어가도 괜찮을 것 같은데 말이죠... :D

[tomyun]

CORS 설정을 강제 적용한 HTTP 서버를 띄우고 테스트해본 적이 있는데 원 페이지가 다운로드된 보안메일처럼 file://인 경우에는 Origin (document.domain)이 null이라 아예 비교 자체를 하지 않고 막아버리는 것 같더라구요.

http://stackoverflow.com/a/3744697/563616

여기 답변을 봐도 일단 file://은 쓰지 말라고 되어 있길래 안 되겠다 싶어서 외부 서버 방식을 고려하게 되었습니다^^;