Re: (의견 문의^^) KIG에서 논의할 아이템...

안녕하세요. 오드컨셉 / W3C Technical Architecture Group 문상환입니다.

> 저는 귀하를 메일링에 참조나 숨은 참조로 포함시킨 적은 없습니다.
> 그래서 어떻게 내 메일에 직접적인 답변을 보냈는지는 의아하군요.

저는 리스트에 대한 의문을 내고 답변을 했을 뿐, 누군가를 지명해서 한 이야기는 아닙니다. (최근에 구독 해지한
ML중에서 아직도 메일이 오는 곳이 있는 것으로 봐서는 w3.org 쪽 버그가 의심됩니다만...)

> 제가 사실 웹어셈블리가 WebGL처럼 W3C 표준이 아니고 앞으로도 그럴 계획이 없다는 걸 알고 있었는데

https://lists.w3.org/Archives/Public/public-new-work/2017May/0009.html


아직 완료된 상태는 아닌 것으로 알고 있습니다. (챠터링 자체는 AC/AB쪽 일이라 신경을 많이 안쓰고 있습니다.
만들어지나 마나 여부의 문제가 아니라 언제냐의 문제인 상황인건 확실합니다만..)

> 근데 굳이 DOM 접근이 필요할까요? Web Worker도 DOM 접근 막았는데.

Worker는 명확히 이야기하자면 DOM 접근을 막은게 아니라, 피한 경우입니다. main thread의 렌더룹에
지장을 주지 않기 위한 타협책이었습니다. Python의 GIL 회피를 위한 multiprocessing 편법하고 유사한
문제라고 생각하시면 될 것 같습니다.

효용도 자체에 많은 영향을 끼칩니다. 실질적으로 main thread를 막지 않는게 주 목적인 Workers의 경우
적용 사례가 꽤 제한적이라는 문제가 있었습니다.

단적인 예로, 성능 우선 UI 프레임웍을 만든다고 할 경우, worker에서 virtual dom을 구성을 한다거나 하는
사례를 생각해볼 수 있는데요, (세만틱에 대한 최소한의 보장이라도 하겠다면 이런 방법이 최선인 현실입니다.)
궁극적으로는 어느 시점에서는 메인 스레드로 구성된 DOM의 부산물이 넘어와야 합니다. 이럴 경우, off thread로
한 작업양이 많으면 많을수록 상대적으로 동기화해야할 내용이 많다는 이야기도 되니, 메인 스레드를 막아야하는
시간이 길어진다는 문제가 있습니다.

WebASM 코드에서 DOM으로 역으로 호출을 할 수 없는건 플랫폼 기능으로서 사실 굉장히 큰 제약사항입니다.
모든 호출시 JS쪽에서 필요한 state를 다 전달을 해야하는 문제가 발생하니까요. Worker도 같은 문제로
굉장히 제한된 케이스에서만 사용이 되고 있습니다.

하기 답변에 명세된 이유들로 유기적으로 동작하는것이 만만치 않은 작업인건 사실입니다. 다른 플랫폼의
FFI와는 워낙 다른 성질의 문제라.. (유사한 예를 들자면, pypy나 ironpython에서 numpy를 사용하는
못하는 문제와 유사한 문제라고 생각하시면 될 것 같습니다.)

> ECMA와 논의하면서 <script type='module'> 같은 기능이 미래에 추가될 예정

은 맞습니다. 언제 될지는 모르겠습니다만.

감사합니다.
문상환 드림

> On Aug 3, 2017, at 17:27, . 컴포지트 <ukjinplant@msn.com> wrote:
> 
> 
> 안녕하세요. 양욱진입니다.
> 
> 저는 귀하를 메일링에 참조나 숨은 참조로 포함시킨 적은 없습니다.
> 그래서 어떻게 내 메일에 직접적인 답변을 보냈는지는 의아하군요.
> 근데 그래도 컨트리뷰터가 직접 몸소 답변 보내주시다니 기쁩니다.
> 
> 이왕 이렇게 된 거 웹어셈 관련 의견 몇가지 내고자 합니다.
> 그것도 대놓고 답변 보내면서.
> 
> 제가 사실 웹어셈블리가 WebGL처럼 W3C 표준이 아니고 앞으로도 그럴 계획이 없다는 걸 알고 있었는데
> 메일 작성 당시에는 그걸 깜박하고 작성해서 잘못 전달한 부분이 있군요. 정정하겠습니다.
> 
> WebASM에 DOM 얘기는 일단 제가 꺼낸 적은 없지만 관련 내용이 있었나 봅니다.
> 근데 굳이 DOM 접근이 필요할까요? Web Worker도 DOM 접근 막았는데.
> 일단 Use case 보면 거의 게임 엔진으로 연산에 치중된 상태이고, 게다가 canvas 같이 DOM 외의 표현을 주로 이룰 텐데
> DOM 접근에 대해 굳이 더이상의 언급이 공식 문서상에도 없으니 언급은 불필요할 듯 하군요.
> 
> 3번에 대해선 자세한 얘기가 필요한데,
> 공식 문서상에는 현재 방법으론 API 접근 뿐이고 앞으로 ECMA와 논의하면서 <script type='module'> 같은 기능이 미래에 추가될 예정이라고 하는데
> 제가 잘못 받아들였는지 모르겠군요.
> 
> 4번은 이건 그냥 잡담인데, 당연히 자바와 닷넷 다 뚫리다 보니 자연스레 난독화 솔루션이 있고,
> JS보다 더 효율적으로 난독화시켜 자산 보호를 하기 때문에
> 바닐라 JS 난독화보단 유리하리라 생각됩니다. 물론 그 실체는 더 지켜봐야 겠지만요.
> 게다가 비동기 컴파일이면... 오히려 좋죠.
> 특히 게임 엔진 자체자 큰 자산인 게임 벤더들이 이 현상에 대해 가만히 있을리 만무하고요.
> 
> 뭐 일단 생각나는 건 여기까지입니다. 웹 연구할 시간 없다보니 시야가 좁아 터져 답답하군요.
> 그럼 이제 슬슬 퇴근시간 다가오는데 마무리 하고 즐거운 퇴근하시길
> 
> 감사합니다.
> 
> 보낸 사람: Sangwhan Moon <sangwhan@iki.fi>
> 보낸 날짜: 2017년 8월 2일 수요일 오후 3:36
> 받는 사람: KIG HTML; public-html5kr@w3.org
> 제목: Re: (의견 문의^^) KIG에서 논의할 아이템...
>  
> 안녕하세요, 오드컨셉 / W3C Technical Architecture Group 문상환입니다.
> 
> 메일이 너무 많아 구독해지를 한 기억이 있는데, 어째서인지 메일이 들어와 있어서... (누군가가 BCC를 한걸까요?)
> 
> WebASM에 대한 오해를 풀기 위한 몇 가지 팩트:
> 
> 1. WebASM은 완성된 기술이 아니며, 표준은 더더욱 아니고, 관련된 API들은 지금 이 순간도 변동의 여지가 있습니다. 단적인 예로, 비동기 컴파일이 지지난주였나.. 추가되었습니다.
> 2. WebASM은 DOM을 접근하지 못합니다. Java로 따지면 JNI 같은 느낌으로 별세계로 객체를 끌고 가는 느낌이라고 생각하시면 됩니다.
> 3. WebASM은 <script src="whatever.wasm"> 형태로 import가 이루어지지 않습니다. (가장 많이 하는 오해 중 하나)
> 4. WebASM은 *최적화되지 않은* IL 기반으로 역컴파일이 비교적 수월하므로 민감한 코드를 보호하는데 큰 도움이 되지는 않습니다.
> (Java나 .NET IL의 역컴파일이 가능하듯, 누군가가 마음 먹으면 어렵지 않게 알아볼 수 있는 수준의 소스를 끄집어낼 수 있습니다.)
> 
> --- 부연 설명 ---
> 
> 하기 언급된 WebAssembly는 "표준"이 아닌 "명세서" 입니다. Rec 트랙 통과하기 까지는 꽤 많은
> 시간이 걸릴 것 같고, 아직 컴파일 관련 API들이 변경되고 있는 상황으로, 아직 실험적인 목적
> 밖에서 사용하기에는 시기적으로 이른 감이 있습니다.
> 
> 재미있는 사실 하나를 공유해드리자면, WebASM의 가장 강력한 숨은 드라이버 네이티브 엔진을 갖고
> 있는데 웹으로 포팅을 불편하게 하고 있는 게임 엔진 벤더들입니다. (e.g. Unity, Epic 등) 따라서, 첫
> 릴리즈는 해당 use case에 매우 편중된 상태로 개발되고 있습니다.
> 
> 현재 WebASM 모듈과 DOM과의 연동 문제도 아직까지 명확한 안이 나온것이 아니고, 사실 가장
> 큰 난제이기도 합니다. WebASM은 메모리 레이아웃을 그대로 노출하는데, 실질적으로 개별적인
> 브라우저 DOM 요소 구현부 메모리 레이아웃이 다르기 때문에... 단순하게 pass by reference는
> 당연히도 불가능하고, pass by value를 할 경우에는 copy overhead가 있으니 성능에 부정적인
> 영향을 미치게 됩니다.
> 
> 이 문제를 어떻게 해결할지는 명확한 답은 안나온 상태입니다. 얼마전에 회의에서 최소공약수에 해당되는
> 부분들에 대한 공통 구조체를 만들어서 해당 인스턴스에 reflection을 하는 편법 같은 것에 대한 이야기를
> 잠시 하긴 했는데, 이것도 좋은 방법일지는 모르겠습니다. 단, 이 경우에 reflected object의 개별 속성에
> 대한 쓰기를 WebASM execution context에서 할 경우, write 발생시 양쪽을 다 잠궈야하는 문제가
> 있습니다. sync-on-write를 하더라도 비슷한 문제가 있습니다.
> 
> (결국 결론은 안났습니다. 모든 객체에 대해서 reflector를 만드는 일도 만만치 않을 것 같고...)
> 
> UI에 WebASM을 사용하는데에 있어서 가장 큰 걸림돌이 되지 않을까 싶습니다. 이번 TPAC때 시간이
> 허락한다면 들러서 이야기를 좀 해보려 합니다. 좋은 아이디어가 있으면 귀뜸해주시면 참고하여 의견 들고
> 가겠습니다.
> 
> 단, (제가 아는 한도 내에서) intermediate language 자체는 고정된 상태니 컴파일러를 만드는 경우라면
> 크게 걱정은 없을 듯합니다. (이전에 SIMD관련해서 넣는다는 이야기를 줏어본것 같은데, SSE / NEON
> 두 마리 토끼를 다 잡으려면 글쎄요...)
> 
> --
> Sangwhan Moon | @sangwhanmoon
> 
> 추신: ML 구독 해지 상태여서, 제 의견이 필요한 부분이 있다면 CC에 넣어주셔야 합니다.
> 
> > On Aug 2, 2017, at 15:02, . 컴포지트 <ukjinplant@msn.com> wrote:
> > 
> > 안녕하세요. 양욱진입니다.
> > 오랜만에 메일링이 왔는데 놓칠 순 없죠.
> > 
> > 뭐 그냥 사소한 의견 하나 낼려고 한번 껴봅니다.
> > 
> > 웹어셈블리가 가장 중요하고 주목해야 하는 이유는 아무래도 산업계에 있죠.
> > 자바스크립트의 소스 코드 보호는 아마 신경 안 쓴 업체가 있을까 하고싶을 정도로.
> > 하지만 웹어셈블리가 웹표준이 되어 범용적으로 사용할 수 있다면
> > 더 다양하고 빠른 웹 앱을 만들 수 있으면서, 지적 재산권 보호가 강화될 수 있다는 기대감. 이거 참 흥미롭습니다.
> > 
> > 일단 저의 개인적인 생각인데, 왠만한 클라이언트 신규 기능을 웹어셈블리에 대동단결 했으면 어떨까 싶습니다.
> > 오토모티브와 웹페이먼트, VR 등등 하드웨어와 직간적접으로 엮이는 것들 말이죠.
> > 어찌보면 개발적 접근이 어려울 수도 있겠지만, 모듈 구현체가 많아져 브라우저 개발 및 사용자 접근성, 성능에 우려를 지울 수가 없더군요.
> > 마치 브라우저 하나에 엄청 많은 확장을 끼고 웹서핑한다는 느낌을 지울 수가 없습니다.
> > 뭐 그냥 그렇다고요. 잡담이니 넘어가시고.
> > 
> > 이제 본문으로 한번 의견을 제시해보고자 한다면은 뭐 작년인가 제작년인가 얘기했던 거 또 얘기했을 수도 있습니다.
> > 요즘에는 하이브리드 앱에 많은 관심이 가고 있습니다. 프론트엔드는 웹으로 백엔드는 응용으로. 대표적으로 Electron 이죠.
> > 많이 알려지진 않았는데 왠만한 하드웨어 제조사나 백신 업체 등은 Sciter 라는 상용 프레임워크를 통해 네이티브 백엔드와 웹 프론트엔드의 장점을 합쳐 앱을 만들고 있습니다.
> > 삼성 계신분들이라면 다 아실 겁니다. 아 참고로 전 소속없는 프리랜서입니다. 흑.
> > 어쨌든, 이번 웹어셈블리가 빠른 Recommendation 등급에 오르길 바라면서, 이에 수혜를 많이 받을 것으로 예상되는 하이브리드 데스크탑 앱에 대한 관심을 가지고 나갔으면 합니다.
> > 하이브리드 모바일 앱은 아시죠? 프론트엔드는 웹, 백엔드는 모바일 네이티브. 그거의 데스크탑 버전인 거죠.
> > 여기서 가장 큰 이슈가 바로 백엔드 소스 코드 노출이긴 한데, 이미 방법은 오픈소스로 생겨났습니다.
> > 하지만 웹 어셈블리가 가세하면 이제 더이상 웹에 성능을 논할 건더기는 줄어드는 거죠.
> > 
> > 뭐 말 길게 늘어놓긴 했는데, 의견의 요지는 이겁니다. 이제 우리도 하이브리드 데스크탑도 논할 때 되지 않았나 이겁니다.
> > 뭐 가능하면 제가 먼저 총대 매도록 하겠습니다. 지금 액티브엑스 기반 개발 프로젝트에 참여중인 건 함정이지만.
> > 아직 딱히 명칭이 정해진 게 아닙니다. 하이브리드 데스크탑은 제가 지은 용어고요. 웹이라도 GUI 응용 프로그램이다 보니 Desktop GUI Framework 범주에 속합니다.
> > 아직 모호한 명칭 때문에 Electron과 같은 범주에 들어가는 프레임워크로 Apache Cordova가 있죠. 모바일인데...
> > 
> > 이상입니다.
> > 하일 엑스플랫폼...
> > 
> > nw.js 가 랜섬웨어 UI 프레임워크 오명을 씌운 게 너무나 슬픕니다...
> > 
> > 보낸 사람: 이원석 <wonsuk.lee@etri.re.kr>
> > 보낸 날짜: 2017년 7월 28일 금요일 오후 6:25
> > 받는 사람: 김다현
> > 참조: HTML5-KIG (public-html-ig-ko@w3.org); public-html5kr@w3.org
> > 제목: RE: (의견 문의^^) KIG에서 논의할 아이템...
> >  
> > 안녕하세요~ 다현님,
> > 좋은 의견 감사합니다~ 말씀하신데로 Web Assembly에 대한 브라우저 벤더들의 지원은 확실히 빠릅니다~^^
> > 기존의 코드를 활용할 수 있다는 측면에서 활용도가 클 것으로 생각되는데 각 브라우저 벤더들이 바라보는 이익은 아직 잘 모르겠습니다^^
> > (소스: http://caniuse.com/#search=webassembly )
> Can I use... Support tables for HTML5, CSS3, etc
> caniuse.com
> Compatibility tables for support of HTML5, CSS3, SVG and other technologies in various browsers.
> 
> 
> > Can I use... Support tables for HTML5, CSS3, etc
> > caniuse.com
> > Compatibility tables for support of HTML5, CSS3, SVG and other technologies in various browsers.
> > 
> > <image002.jpg>
> >  
> > Web payment의 경우는 정말 빠른 속도로 표준 개발과 브라우저 적용이 되고 있습니다. 제가 본 표준 중에 단연 top speed 입니다^^ 삼성전자도 
> > 크롬, 크롬 for android, edge 그리고 삼성 인터넷 브라우저가 지원합니다. 오프라인 페이도 있지만 온라인에서 웹 페이먼트 생태계 선점을 위한 경쟁도 엄청난 것 같습니다~^^ 
> > http://caniuse.com/#search=Payment%20Request%20API

> Can I use... Support tables for HTML5, CSS3, etc
> caniuse.com
> Compatibility tables for support of HTML5, CSS3, SVG and other technologies in various browsers.
> 
> 
> > Can I use... Support tables for HTML5, CSS3, etc
> > caniuse.com
> > Compatibility tables for support of HTML5, CSS3, SVG and other technologies in various browsers.
> > 
> >  
> > [단독] 삼성전자 갤럭시S8, 세계최초로 W3C 웹결제 표준 적용
> > http://www.segye.com/newsView/20170315003778

> 
> [단독] 삼성전자 갤럭시S8, 세계최초로 W3C 웹결제 표준 적용
> www.segye.com
> '곧 나올 삼성전자 신형 스마트폰의 진수는 고기능 하드웨어가 아닌 첨단 소프트웨어에 있었다 ' 오는 29일 발표되는 갤럭시s8 ...
> 
> 
> > 
> > [단독] 삼성전자 갤럭시S8, 세계최초로 W3C 웹결제 표준 적용
> > www.segye.com
> > '곧 나올 삼성전자 신형 스마트폰의 진수는 고기능 하드웨어가 아닌 첨단 소프트웨어에 있었다 ' 오는 29일 발표되는 갤럭시s8 ...
> > 
> >  
> > 전자화페 관련해서도 현재 blockchain community group에서 웹에서 필요한 표준을 찾아나가는 작업을 진행 중에 있습니다^^
> > https://www.w3.org/community/blockchain/

> Blockchain Community Group - World Wide Web Consortium
> www.w3.org
> The mission of the the Blockchain Community Group is to generate message format standards of Blockchain based on ISO20022 and to generate guidelines for usage of ...
> 
> 
> > Blockchain Community Group - World Wide Web Consortium
> > www.w3.org
> > The mission of the the Blockchain Community Group is to generate message format standards of Blockchain based on ISO20022 and to generate guidelines for usage of ...
> > 
> >  
> > 그리고 WebVR도 기업들이 관심을 많이 갖고 있는 기술이고 현재 WebCR community group을 중심으로 WebVR 표준 초안을 개발 중에 있는데 언제쯤 공식적으로 WG을 만들어서 진행될지 궁금하네요^^
> > https://www.w3.org/community/webvr/

> WebVR Community Group - World Wide Web Consortium (W3C)
> www.w3.org
> Several people asked how active the WebVR community group but had been misled by the lack of visible activity on this blog or on the mailing list.
> 
> 
> > WebVR Community Group - World Wide Web Consortium (W3C)
> > www.w3.org
> > Several people asked how active the WebVR community group but had been misled by the lack of visible activity on this blog or on the mailing list.
> > 
> > https://github.com/w3c/webvr/

> 
> GitHub - w3c/webvr: Repository for the WebVR Community ...
> github.com
> webvr - Repository for the WebVR Community Group and the WebVR Specification.
> 
> 
> > 
> > GitHub - w3c/webvr: Repository for the WebVR Community ...
> > github.com
> > webvr - Repository for the WebVR Community Group and the WebVR Specification.
> > 
> > https://w3c.github.io/webvr/spec/latest/

> >  
> > 마지막으로  WebRTC와 WebVR 간의 시너지도 말씀하신데로 기대가 되는 부분이기 한데 시간이 좀 걸릴 것 같습니다~^^
> > 의견 감사합니다~
> >  
> > 이원석 드림.
> >  
> > From: 김다현 [mailto:coremaker@gmail.com] 
> > Sent: Friday, July 28, 2017 12:17 AM
> > To: 이원석 <wonsuk.lee@etri.re.kr>
> > Subject: Re: (의견 문의^^) KIG에서 논의할 아이템...
> >  
> > 안녕하세요. 김다현 입니다.
> > 오랫만입니다. 잘 지내시죠? 다음은 최근 가지고 있는 생각을 정리한 의견입니다.
> >  
> > 표준화 관련 진행 방식에 대해서 정확히 알지는 못하지만,
> > 최근 WebAssembly 진행 과정을 보면 이전과 달리 표준화 진행 전부터 MS/애플의 구현이 눈에 띕니다.
> >  
> > 단적인 예로 WebSocket을 제외한 Web Crypto 라던지 WebRTC 등은 동일한 스펙의 구현이
> > 적용되는데 엄청난 시간이 걸린 반면, WebAssembly는 굉장히 체계적으로 빠르게 진행되지 않나 싶습니다.
> >  
> > 각 주요 벤더 마다 셈법은 다르겠지만
> > 내년 쯤에 표준화의 단계가 어느 정도 진행되고 나서는 매우 주목 받는 표준 기술이
> > 되지 않을까 싶습니다.
> >  
> > 그 외 Web Payment와 관련해서 최근 블록체인 기술을 활용한 bitcoin / 이더리움 등 
> > 다양한 형태의 전자 화폐와 관련된 이슈들이 내년 쯤 불거질 가능성이 높다고 생각합니다.
> >  
> > Web Payment를 화두로 시작하여 웹 기반의 블록체인 기술이 DRM(워터마크와 같은 추적기술) 등 
> > 저작권 보호와 관련 부분에서도 활용될 수 있는 여지가 있지 않을까 생각합니다.
> >  
> > 추가적으로 
> > WebRTC와 WebVR 간의 기술 시너지 도 주목해야하는 부분으로 보고 있습니다.
> >  
> > 감사합니다.
> >  
> > 2017년 7월 27일 오후 11:58, 이원석 <wonsuk.lee@etri.re.kr>님이 작성:
> > 안녕하세요~ ETRI 이원석입니다~
> > 제가 한동한 뜸했죠?^^ 다시 KIG 활동을 정기적으로 갖을려고 합니다~ J 관심있는 분들의 적극적인 참여를 부탁드립니다~
> > 생각나는데로 KIG에서 소개할 만한 내용들을 아래와 같이 적어봤는데~ 의견 부탁드려요~ 새로운 아이템이 아니더라도 아래 내용 중에 관심있는 내용에 대해서 의견 주셔도 좋습니다^^
> >  
> > -      2017년 HTML5 업계 및 W3C 표준 동향
> > -      React vs Angular vs Vue
> > -      브라우저 동향(크롬, edge, safari, Mozilla 등)
> > -      크로미움 오픈소스 현황 및 계획
> > -      Why Typescript than Javacript?
> > -      Gulp and webpack
> > -      WebRTC 기술/업계/표준 동향
> > -      Web Assembly
> > -      Web Payment
> > -      Automotive Web
> > -      ???
> >  
> > 감사합니다!
> >  
> > 이원석 드림.
> 

Received on Thursday, 3 August 2017 11:08:01 UTC