- From: Sangwhan Moon <sangwhan@iki.fi>
- Date: Fri, 4 Aug 2017 17:49:17 +0900
- To: 김다현 <coremaker@gmail.com>
- Cc: KIG HTML <public-html-ig-ko@w3.org>, "public-html5kr@w3.org" <public-html5kr@w3.org>
안녕하세요. 업무중이라 자세한 답변은 못드립니다만, 하기 예시는 primitive type이니 사양내에서 정상적인 사용이 맞습니다. 실질적으로 linear memory buffer로 모든걸 할 수 있지만, 결국 webasm에서 받은걸 JS쪽 execution에서 재해석을 하는 과정이 들어가는데 이게 DOM object에 저쪽에서 작업한 것들을 동기화해 넣는 동안은 main thread에 대한 부하와 jank를 피할 수 없는게 현제 제약 사항입니다. DOM이 있는 execution context에서 WebASM으로 넘어갈때, Object pointer를 넘겨 받아 WebASM에서 바로 변경해야 될 것들을 반영할 수 있는 시점까지는 사용할 수 있는 예가 제한적이라는 이야기가 됩니다. (JNI와 같은 다른 플랫폼의 사례를 보면 FFI에서 지원하고 있는 기능들입니다. 구현 속도만을 생각한 적당한 타협점으로 한다는 점이 매번 아쉽습니다.) > 동기화 이슈 등의 문제로 다른 스레드에서 직접 UI 핸들링을 하는 것을 제한하는게 일반적으로 알고 있습니다. > > web worker도 당연히 main thread 동작의 일부인 dom 핸들링을 제한하는 것은 당연한 것이라고 판단하구요. > 그와 조금 다르지만 wasm 도 별도의 메모리 영역과 스레드를 통해 접근하는만큼 같은 정책이 적용되었을 것이라 판단합니다. 사실, 이런 문제는 이미 과거 OS에서 해결된 바 있는 문제인데 (단적인 예로, cooperative multitasking 방법론이 있습니다.), 궁극적으로는 웹의 컨텐츠의 현실에 최적화하여 main thread의 jank 방지를 위해 무수하게 많은 편법들이 들어가 있고, 그러한 최적화의 기술 부채로 preemptive multitasking 모델로 개발 된 점이 어찌 보면 장기적으로 웹 플랫폼이 해결해야할 문제가 아닐까 하는 생각입니다. 감사합니다. 문상환 드림 -- Sangwhan Moon | @sangwhanmoon > On Aug 4, 2017, at 13:38, 김다현 <coremaker@gmail.com> wrote: > > 안녕하세요. 김다현 입니다. > > 좋은 정보 감사합니다. 많이 배우네요. > > wasm에 callback 을 구현한 사례가 있어서 찾아봤습니다. > 다만, 이게 공식적인 표준화 프로세스 안에서 제공하는 방식으로 실행하는 것인지 아니면 emcc 의 특성을 이용해서 우회하는 방식인지는 잘 모르겠습니다. > > github : https://github.com/shogonir/wasm-sample/blob/master/03-wasm-callback/index.html > blog : http://shogonir.hatenablog.com/entry/2017/05/19/012343 > > 만약 위의 블로그된 포스트 정보가 정상적인 동작범위에서 실행된 것이라면, js에 대한 함수 레퍼런스 테이블을 wasm 내부에서 참조할 수 있는 것으로 보입니다. > wasm을 jni와 비교하였을 때 좀 다른 부분이 되겠지만 이부분은 진행되는 스펙이나 정보가 더 필요합니다. > > --- > > DOM 핸들링 관련해서는 다음과 같이 생각합니다.\ > > 우선 wasm과 domscript 간 데이터 통신이 많아 지면 성능면에서 불리해지는 건 사실인 것 같습니다. > > 다만 이런 부분은 목적에 따라서 잘 구조화 하고 wasm 내의 linear memory buffer를 js쪽에서 바로 볼 수 있기 때문에 dataview 를 잘사용한다면 > 조금이라도 활용성을 확대할 수 있으리라고 봅니다. > > 그리고, > > 일반적인 UI를 제공하는 프레임워크에서 UI와 밀접한 프로세스는 대부분 main thread 에서 사용하고, > 동기화 이슈 등의 문제로 다른 스레드에서 직접 UI 핸들링을 하는 것을 제한하는게 일반적으로 알고 있습니다. > > web worker도 당연히 main thread 동작의 일부인 dom 핸들링을 제한하는 것은 당연한 것이라고 판단하구요. > 그와 조금 다르지만 wasm 도 별도의 메모리 영역과 스레드를 통해 접근하는만큼 같은 정책이 적용되었을 것이라 판단합니다. > > > 감사합니다. > > > > 2017년 8월 3일 오후 8:07, Sangwhan Moon <sangwhan@iki.fi>님이 작성: > 안녕하세요. 오드컨셉 / 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 Friday, 4 August 2017 08:49:47 UTC