https://discuss.haiku-os.org/t/webkit-status/8822/4

 

WebKit status?

Didn’t realize that… well that’s going to be useful. Also Webkit 1 stability is much better as of late… it will be nice for it to not bring down the whole browser if a bug or two does sqeak by though. I do wonder what change made it more stable…

discuss.haiku-os.org

한때, WebKit Project가 잘 나가던 시절이 있었다. Mac, Gtk+, EFL, Qt, Haiku 등 여러 포팅 레이어를 지원했고, 다양한 구성원으로 구성된 공동체가 있었다. 하지만, 2013년 구글을 프로젝트를 포킹하고 나서  WebKit Project는 급속도로 쇠락했다. 많은 회사들이 Chromium으로 옮겨갔고 현재는  Gtk+ 포트만이 유일한 외부 포트로 살아남았다. 원래 각 포트는 자신들의 리뷰 권한이 있었는데, 이를 애플 리뷰를 받도록 강요하면서 공동체가 와해되는 게기가 되었다. Haiku port는 이미 오래전에 WebKit에서 제외된 포트지만, 공동체내에서 활발하게 구현이되고 웹킷2까지 지원하고 있다. 물론, 한 사람이 열심히하고 있지만 어찌되었던 다시 웹킷에 추가될 가능성도 보이는 것 같다. Haiku Project는 오래전 BeOS를 사용해본 경험이 있어서 꾸준히 관심을 갖고 있는데, 시간이 되면 Haiku WebKit port를 한번 빌드를 해봐야겠다.

WebKit에서 구현된 하드웨어 가속과 WebKit-Clutter를 소개합니다.

작년에 이어 WebKitGtk+ Hackfest 2011에 참석했다. 작년에 이어 같은 장소인 스페인 코루나에서 열려서 그런지, 이제 스페인이 제2의 고향 같다는 느낌이 들 정도다. 물론 스페인은 말은 아는게 "올라"가 전부다. ^^;

작년과 다른 점이 있다면 이번에는 너무나 큰 할 일꺼리를 가지고 갔다는 점이다. 그 동안 webkit-clutter 포트에 작업한 Accelerated Compositing 기능을 WebKitGtk+에 적용하는 것! 너무나 큰 욕심이었을까? 집에 돌아와서 겨우 초기 patch를 반영했다. 어찌되었던 동작하는 데모를 만들었다는데 위안을 삼을 수 있었다. 이외 많은 관심사가 논의되고 해결되었다.

WebKit은 정말 뜨거운 프로젝트다. 이런 프로젝트에 참여하고 있다는 것 자체가 신기할 따름이다. 하지만, 나름 WebKit을 일찍 알아보고 꾸준한 관심을 가져온 결과인 것 같다. 2007년에 QT용 WebKit을 처음으로 TV에 포팅했었으니까, 벌써 4년전 일이다. 안타까운 것은 Mozilla 프로젝트에는 관심을 가질 여유가 없다는 점. 다행스러운 점은 WebKitGtk+를 통해 GNOME기술에 눈을 뜬 점.

얼마전 HP WebOS가 오픈소스 프로젝트가 된다는 발표가 있었다. 내년에는 웬지 할일이 더 많을 것 같다.

지난달에 이어 같은 주제로 발표한 내용을 공유합니다.

특히, 아래 Reflow를 줄이는 방법에 대한 글을 요약했는데, 웹페이지 성능 향상에 도움이 될 것입니다. 

• How (not) to trigger a layout in WebKit
• Rendering: repaint, reflow/relayout, restyle

요즘 화제가 되고 있는 "How browse works"글을 요약 발표했습니다.

지난 달에 제 6차  W3C  HTML5 KIG Meeting에 처음으로 참석하게 되었다.  이 모임은 국내 HTML5 표준화에 관심을 갖는 분들이 모여 HTML5 표준화 현황을 나누고 논의하는 자리이다.  이번 모임에서는 HTML5 Web App, Device API, Navigation Timing Spec에 대한 소개가 진행되었는데, 실제 WebKit에서 어떻게 지원되고 있는지  간단하게 정리해보았다.

Custom scheme and content handlers

브라우저에서 사용하는 Protocol이나 mimetype을 임의로 등록하여 특정 URL에서 처리하도록 하는 기능이다. 즉, http://, ftp://와 같은 Protocol을 브라우저에 임의로 등록할  수고 있고, 이를 Protocol로 요청이 들어오면 특정 URL이 처리할 수 있도록 한다. 아래와 같은 인터페이스를 지원하고 있고, 실제 Spec은 여기서 확인할 수 있다.

window.navigator.registerProtocalHandler(scheme, url, title)
window.navigator.registerContentHandler(mineType, url, title)

예) navigator.registerContentHandler('application/x-soup', 'soup?url=%s', 'SoupWeb'')

위 Feature는 WebKit에 구현되어 있지만, 아래와 같이  Build할 때, enable해야 사용할 수 있다. 하지만, 아직은 Chromium에서만 지원하는 듯 보인다.

WebKit/Tools/Scripts/build-webkit --register-protocol-handler

실제 구현은 된 초기patch는 여기서 확인 가능하다. 최근, 이미 사용 중인 protocol에 blacklist 를 각 브라우저 개발 업체로 부터 수집하였고, 이에 대한 처리가 WebKit에 반영되었다.

AddSearchProvider

Search Box에 검색 엔진을 등록하는 기능인데, 이 역할을 UI에서 할지 Engine에서 해야할지 아직 논란이 있다. 이미 IE와 Firefox에서 지원하고 있지만, WebKit Community내에서는 합의가 필요한 상태다.

지원하는 interface 는 다음과 같다. 

window.external.AddSearchProvider()
window.external.IsSearchProviderInstalled()

whatwg에 다음과 같이 제안이 이루어졌고,

[whatwg] Proposal for IsSearchProviderInstalled / AddSearchProvider

WebKit에도 오래전에 버그로 등록은 되어 있지만, 현재로서는 구현 계획이 없다.

그러면, 브라우저에서는 어떻게 사용하는지 살펴보자.

• Firefox에서 AddSearchProvider 사용하기

• IE에서 AddSearchProvider 사용하기

• Chromium에서 지원

Google에서 WebKit에 반영하도록 노력한다고 하니, 진행 과정을 지켜봐야겠다.
 

HTML Media Capture

Device API Spec은 특히 Mobile분야에서 관심이 많은데, Web App과 Native App간의 경계를 허무는 작업이라고도 할 수 있다. 그 중에서 HTML Media Capture Spec은 User Agent에서 device의 microphone과 camera에 접근하도록 한다. 현재 WebKit에는 버그만 등록된 상태이다.

Navigation Timing

지금까지 웹 성능을 측정하는 일은 브라우저 개발자만이 가능한 일이였다. 브라우저 개발자도 HTTP 모듈까지 소스코드로 접근해야만 어느 정도 측정이 가능했었는데, 이를 웹 개발자도 가능하도록 Navigation Timing이라는 Spec이 표준화 중에 있으며, 이미 Chromium은 지원하고 있고, 데모 페이지에서 테스트할 수 있다. 이를 통해 Page를 요청하여 로딩하는 전 과정에서 얼마나 시간이 걸리는지 단계별로 Profiling 할 수 있게 된다. 현재, GTK+ port, QT port에서 이를 구현하고 있다.

앞으로 매달 열리는 HTML5 KIG Meeting에서 논의된 웹표준 내용을 가운데, WebKit에서 얼마만큼 구현하고 있는 소개할 예정이다.

참고

• 이재환님 Web Application APIs 발표 자료
  

지난 4월 24,25일 미국 Apple본사가 위치한 Cupertino에서 열린 WebKit Contributors meeting 2011에 참석했습니다. 본 행사는 WebKit Contributor가 한 자리에 모여, 당면한 문제와 앞으로 계획 등을 논의하는 자리입니다. 올해가 두번째 열렸으며, unconference형식으로 진행되는 행사입니다. 지난 1년간 함께 WebKit을 개발해온 사람들이 함께 모이는 축제라고도 할 수 있겠지요. 이번 모임에서 어떤 논의가 있었는지 간단하게 소개하도록 하겠습니다.

WebKit은 모바일 브라우저 엔진 뿐만 아니라 Mobile Platform으로도 사용되고 있기 때문에 Apple과 Google뿐만 아니라, Nokia, RIM, Samsung, Motorola, Ericsson, Sony, Igalia, Sencha 에서도 참석하였고, 저도 Collabora를 대표해서 참석하였습니다.  지난 WebKitGtk+ Hackfest 참석 멤버들도 다시 만나서 반가웠고, 제 Patch를 review해주던 Reviewer도 실제로 만나니 더 반가웠습니다. 오픈소스 프로젝트에 참여하는 맛이 이런게 아닌가 싶었습니다. 

진행된 Session과 내용은 대부분 인터넷에 공개가 되어 있어서, 어떤 논의가 오고갔는지 확인할 수 있습니다.  무엇보다도 관심은 WebKit2였습니다. 작년에 Apple이 소개한 WebKit2는 그 동안 Qt와 Gtk+ Port팀도 활발하게 작업을 진행하고 있습니다. 사실, WebKit2는 WebCore를 제외한 API영역과 Web Process와 UI Process를 새로 개발하기 때문에 그리 간단한 일은 아닙니다. 이날도 많은 Issue가 쏟아져나왔는데, 몇 가지를 소개하면 다음과 같습니다.

• C API사용이 최선인가? 이미 Qt는 C++ API를 사용하고 있습니다.
• plugin을 별도 process로 실행하기. 곧 Apple이 소스를 공개한다고 합니다.
•  WebKit1과 WebKit2와 중복 code를 어떻게 줄일까요?
• DRT를 다시 작성하는일, WebKitGtk+의 경우 WebKit1용 DRT도 아직 완벽하지 않습니다.
• theaded model 지원하기. mobile device에서 각 page마다 web process를 실행하는 것은 다소 부담스러운 일입니다.
• web process와 ui process과 통신하는 부분이 너무 platform 의존적으로 개발되어 있어, 뭔가 추상화 모델이 필요합니다.
• Mac에서 구현한 접근성 기능을 다른 port에서는 따라하기가 쉽지 않다고 합니다.
  

WebKit Party Poster