없으면 없는대로

본 기사는 2008년 12월 버전 (rev. 39476) WebKit win32 port를 기준으로 한다.

http://webkit.org에 존재하는 “WebKit Objective-C Programming Guide” 문서를 보면 다음과 같은 그림이 존재한다.

• WebView는 WebKit 엔진을 담고 있는 main-window를 나타내는 개념이다.
• WebFrame은 WebKit이 표시하는 페이지를 나타내는 개념이다.
• WebView는 1개의 WebFrame을 main-frame 멤버로 갖는다.
• WebFrame은 0개 또는 여러 개의 WebFrame을 children 멤버로 가질 수 있다 (HTML & 태그 처리…).

화면 구성 요소들에 대한 클래스 다이어그램은 다음과 같다.

WebKit의 핵심 시퀀스를 요약하면 아마 다음과 같을 것이다.
- URL 문서를 loading 하는 시퀀스
- loading한 문서를 parsing 하는 시퀀스
- parsing된 내용의 layout을 결정하는 시퀀스
- 구성한 화면을 출력하는 시퀀스

이들중 "URL 문서를 loading하는 시퀀스"를 분석하게 됐다.
WebKit을 갖고 일하는 개발자들에게 조금이라도 보탬이 되면 좋겠다. 혹시나 분석한 내용에 오류가 있다면, 댓글이나 트랙백으로 가르침 주시기 바란다. 분석에 사용한 WebKit은 작년말(2008년 12월) 버전이며 (rev. 39476), cURL을 사용하는 win32 port를 기준으로 하고 있다.

URL을 load 하는 시퀀스를 분석하면서 WebKit에 존재하는 수 많은 종류의 loader들 때문에 골치 아팠다. 대강의 내용을 정리하면 다음과 같다 (클래스 다이어그램에 메모박스로 주석 달아 놓았다).
- FrameLoader : URL-load 과정을 총괄하는 loader (1개의 frame에는 여러개의 web-page가 load될 수 있다).
- DocumentLoader : 1개의 web-page load를 책임지는 loader.
- MainResourceLoader : base-document (HTML 문서) load를 책임지는 loader.
- ResourceLoader : sub-document (CSS, js, image, ...) load를 책임지는 loader.

분석한 내용을 다음 2장의 UML 다이어그램으로 정리한다. 이미지를 클릭하면 원본 크기로 볼 수 있다.


<<URL load 과정에 참여하는 Class 들>>

<<URL load 간단 시퀀스 (HTML 파일 1개로만 이루어진 페이지 load 시퀀스)>>

분석을 위해 다음과 같은 뉴스그룹 기사들을 참고했다. 다른 사람들에게도 참고가 되기를 바라며, 해석 없이 그대로 올린다.

"문서 load 시퀀스"
from http://osdir.com/ml/opendarwin.webkit.devel/2006-10/msg00041.html
======================================================================

Main resource loaded, started from app via API:

[ WebFrame ] (ObjC, WebKit)
[ FrameLoader ] (C++, WebCore) ---> [ FrameLoaderClient ] (C++ abstract base class, implemented in webkit to deliver delegates)
 [ DocumentLoader ] (C++, WebCore)
[ MainResourceLoader ]  (C++, WebCore)
[ ResourceLoader ] (C++, WebCore)
[ FrameLoader ] (C++, WebCore)

Main resource loaded, started from engine via link click or form submission:

[ FrameLoader ] (C++, WebCore) ---> [ FrameLoaderClient ] (C++ abstract base class, implemented in webkit to deliver delegates)
 [ DocumentLoader ] (C++, WebCore)
[ MainResourceLoader ]  (C++, WebCore)
[ ResourceLoader ] (C++, WebCore)
[ FrameLoader ] (C++, WebCore)

Subresource load:

[ DocumentLoader ]  (C++, WebCore)
[ Cache ] (C++, WebCore)
[ FrameLoader ] (C++, WebCore) ---> [ FrameLoaderClient ] (C++ abstract base class, implemented in webkit to deliver delegates)
 [ SubresourceLoader ] (C++, WebCore)
[ ResourceLoader ] (C++, WebCore)
[ Cache ] (C++, WebCore)
[ CachedResource ] (C++ WebCore)

"Loader의 종류 및 역할"
from http://www.nabble.com/Role-of-all-loaders-to22115931.html#a22172592
========================================================================

Re: Role of all loaders  
by Darin Adler Feb 24, 2009; 08:28am :: Rate this Message:    (use ratings to moderate[?])

> FrameLoader

Controls the process of loading web pages into a frame. Contains all  
the loading-related functions and data instead of having them all on  
Frame itself. There’s one of these for each frame.

> DocumentLoader

Controls the process of loading one particular web page into a frame.  
When a new page is loaded, the frame loader creates a new document  
loader and then later destroys the old one.

> DocLoader

Part of the caching machinery. Manages the cached loading for a  
particular document. May be merged with DocumentLoader at some point  
in the future, or perhaps renamed.

> MainResourceLoader

FrameLoader and DocumentLoader use ResourceLoader objects to load  
individual resources. The main resource is the HTML file (or SVG file  
or whatever). The ResourceLoader for the main resource is a  
MainResourceLoader.

> Sub resource Loader

The ResourceLoader objects for subresources such as images, scripts,  
and CSS style sheets are SubresourceLoader objects.

     -- Darin

"URL loading중 발생하는 frameLoaderClient를 통한 이벤트"
from http://www.nabble.com/FrameLoaderClient-notifications-to16025970.html#a16030339
=====================================================================================
Re: FrameLoaderClient notifications  
by Darin Adler Mar 14, 2008; 02:37am :: Rate this Message:    (use ratings to moderate[?])

> I suppose the following order of loading events for a page with a  
> single frame (please, correct me, if I'm wrong):
>
> page load started
> main document load started
> title received
> icon received
> * main document load finished
> ** resource load started
> resource load finished
> page load finished
...[show rest of quote]

The the FrameLoaderClient functions about the frame (not the ones that  
take DocumentLoader*) are what you want. They are all about this  
cycle. dispatchDidStartProvisionalLoad is the one that goes first, and  
then there are quite a few others, ending with dispatchDidFinishLoad,  
dispatchDidFailLoad or dispatchDidFailProvisionalLoad.

> OK, I see. Is there any other load process other than provisional?

All loads start provisional.

>> dispatchWillSendRequest will be called repeatedly with different  
>> URLs when a server does redirection. This is normal. How it should  
>> be handled depends on what API you've devised.
>
> Is there any separate notification about redirection, or this method  
> is enough?

There is
dispatchDidReceiveServerRedirectForProvisionalLoad for loads of the  
main resource of a frame, but dispatchWillSendRequest alone is all  
that's needed for arbitrary resource loads.

> One more question: is there any method about starting loading of an  
> external resource? Is it dispatchWillSendRequest?  
> dispatchDidReceiveResponse?

assignIdentifierToInitialRequest and dispatchWillSendRequest

     -- Darin

"HTTP 스택은 누가 처리하나?"
from http://www.nabble.com/Complicated-Loaders-to18706606.html#a18724848
========================================================================

The sequence of FrameLoader and DocumentLoader functions is indeed complicated
and overloaded.  This is slowly being improved over time, little by little. 
And no, there is no documentation at this time.

I'm not sure of the exact motivation for your question, but you did end on
a very specific note so this might be of use.  The question of "how WebKit is
invoking the HTTP stack" is much simpler - the ResourceRequest, ResourceHandle,
and ResourceResponse classes are all fairly encapsulated and represent
HTTP connections.

~Brady

StarUML은 UML을 그리는 도구다.
한 10년 전에는 상용으로 판매됐던 도구인데, 현재는 무료 오픈 소스 프로젝트로 전환됐다. 비싸기로 유명한 Rational Rose를 비롯해서 여러개의 UML 도구를 써봤는데, StarUML이 최고였다. UML이 필요하다면 고민하지 말고 가져다 쓸 것을 권한다. 중요하진 않지만, 자랑스럽게도 우리나라에서 만든 툴이다. 그래서 '한국어'로 된 매뉴얼이 존재한다 (이건 중요하다).

http://staruml.sourceforge.net/ko/index.php

Qt-WebKit을 Windows Mobile 6.1 단말기에 올렸다.
"자, 이젠 빠른 성능과 아름다운 페이지를 보여줘." 하는 마음으로 실행시켰는데... 결론을 말하자면 실망이다. 아직 모자란 점이 많다. 이건 WebKit의 문제라기 보다는 Qt-WebKit의 문제다. 포팅이 불충분하다. 적어도 Windows Mobile에서는 그렇다.

1. 우선 네트웍에 관한 처리가 미흡하다.
스스로 단말의 네트웍 연결을 초기화시키지 못한다. 백그라운드로 Windows Mobile의 Internet Explorer를 실행시켜서 네트웍을 잡고 실행시키면 그나마 조금 상태가 나아진다. 하지만 한 화면을 구성하는 모든 document 들을 네트웍을 통해 다운로드하지 못한다. 화면 상태로 미루어 추정하자면, base HTML document만 다운로드해서 보여주는 것 같다.

2. 속도가 미흡하다.
난 빠른 속도를 기대했다. 적어도 Mobile IE보다는 빠른 속도를 기대했다. 그런데 체감 속도가 IE에 비해 대등하거나 느리다. 이건 Qt 레이어의 오버헤드 때문일 것 같다.

Windows Mobile 단말기가 하나 있다. 이놈 위에 웹킷을 올려보고 싶었다. 이리저리 찾던 중에, Qt WebKit 브라우저가 눈에 들어왔다. 다시 말하지만, 웹킷은 브라우저 엔진일뿐 브라우저가 아니다. 이놈을 브라우저로 동작하게 만들려면 많은 노력이 필요하다. Qt WebKit 프로젝트가 바로 그런 노력을 하고 있는 프로젝트다. 마침 "한.글.로.된." 좋은 블로그 글을 찾아 편안한 마음으로 시도해볼 수 있었다. 자기가 겪은 경험을 글로 정리해서 공개하는 사람들에게 다시 한번 감사하는 마음을 전한다.
http://www.korone.net/bbs/board.php?bo_table=qt_lecture&wr_id=465

하지만, 세상 모든 일이 그렇듯 뭔가 넘기 힘든 고개들이 있었다. 그런 고개들이 있어야 성공했을 때 성취감을 느낄 수 있는 것 아니겠는가? 나 다음 개발자들은 그런 성취감(?)을 느끼지 못하기를 기도하며 몇가지 경험을 정리한다.

처음에는 Cygwin 콘솔창을 열고 작업 했는데, 뭔가 잘 안됐다. 다음의 웹 페이지를 보고 원인을 알게 됐다. Qt WebKit을 Cygwin서 빌드하는 것은 원래 아직 안되는 것이었다 (2008.11.13. 현재). 그래서 WinXP 32bit의 커맨드 콘솔(cmd.exe)에서 작업했다. 커맨드 콘솔에서 작업하려면, 몇가지 GnuWin32 도구들을 설치해줘야 한다. 아래 "빌드 환경" 파트에 관련 내용을 정리했다.
http://trac.webkit.org/wiki/BuildingQtOnWindows

그리고, 빌드할 때 Qt WebKit 소스가 있는 드라이브의 루트 아래에 tmp 폴더를 만들어줘야 한다. 별거 아닌데, 이것 때문에 조금 고생했다.

빌드 환경
- WinXP 32bit
- Qt-wince를 다운로드 받아 빌드 완료한 상태 (참조 URL)
- Qt-WebKit 소스를 다운로드 받은 상태 (E:\Work\QtWebKit에 소스를 다운로드 함)
- 빌드를 위해 필요한 perl 및 GnuWin32 툴들을 설치한 상태 (참조 URL)


빌드 시퀀스