없으면 없는대로

대한민국에서 S/W를 업으로 삼고 있는 회사들은 대부분 용역사업으로 생계를 꾸린다. 나는 어떤 S/W 결과물을 내놓을 때마다 그것을 내 자식이라고 생각한다. 내 자식이 어디 가서 똘똘하다는 이야기를 들어야 부모된 마음이 편하다. 대부분의 부모는 자기 자식이 똘똘해질 때까지 무한 애정을 쏟을 용의를 갖는다. 사실 애 하나 키우는 일이 쉬운 일이 아니다. 세상에 나가서 자기 몫을 충분히 하는 인재를 키워내려면 무척 많은 시간 동안 정성을 쏟아야 한다. 그런데, 용역 사업은 말하자면 자식을 낳아서 다른 곳에 입양시키는 사업이다. 게다가 제대로 키울 틈도 없이 낳자마자 입양시키는 사업이다. 용역이 끝나면 용역 결과물에 대한 모든 권리를 용역 발주처가 갖는다. S/W 개발자 입장에서 보면 무척 슬픈 사업 방식이다. 대한민국 S/W 사업 생태계가 질적으로 도약하려면 이런 사업 방식이 바뀌어야 한다. 할말이 무척 많아서 제목에 '(1)'을 달았다. 또 다른 생각이 정리되면 '(2)'를 달아서 글을 올려야겠다.

W3C의 DOM2 Events Spec을 다음과 같이 요약한다.
http://www.w3.org/TR/DOM-Level-2-Events/


1.1. Overview of the DOM Level2 Event Model
1.1.1. 용어
UI events
user interface event. 마우스, 키보드 등을 통해 사용자가 발생시키는 이벤트

UI Logical events
focus change 또는 element triggering 같은 장치와 무관한 이벤트

Mutation events
DOM 내용이 바뀔 때 발생하는 이벤트

Capturing
event가 event-target에서 처리되기 전에 event-target의 ancestor 들에서 먼저 처리되는 것

Bubbling
event가 event-target에서 처리된 다음 ancestor들로 전파되는 것


1.2. Description of event flow
1.2.1. Basic event flow
event-listener 처리중에 exception이 발생하더라도 evcent는 계속 전파된다.

1.2.2. Event capture
capture는 top node (Document node)에서부터 target node까지 전파된다.
Event::stopPropagation() 메소드로 capturing을 중지시킬 수 있다. 단, stopPropagation()이 호출된 level의 event-listener 들은 모두 호출된다.

1.2.3. Event bubbling
capturer로 등록된 event-listener 들은 bubbling phase에서는 호출되지 않는다.
Event::stopPropagation() 메소드로 bubbling을 중지시킬 수 있다. 단, stopPropagation()이 호출된 level의 event-listener 들은 모두 호출된다.

1.2.4. Event cancelation
cancelable한 event는 Event::preventDefault() 메소드를 호출해서 implementation의 default 동작을 취소 시킬 수 있다. 즉, hyper-link를 클릭해도 해당 link로 이동하지 않게 만들 수 있다.


1.3. Event listener registration
1.3.1. Event registration interfaces
EventTarget::dispatchEvent() 메소드로 이벤트를 직접 전달할 수 있다.
EventTarget::dispatchEvent() 메소드로 이벤트를 fire 시켜도 capturing과 bubbling이 동일하게 발생한다.


(끝)

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

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

이 그림에서 aWebFrameView는 폐기됐다 (적어도 windows port에서는…). 지금 현실에 맞게 그림을 재구성하면 다음과 같다.

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

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

언제나처럼 이미지를 클릭하면 원본 크기로 볼 수 있다.

 

이전 기사에서 사용자가 URL을 입력했을 때, WebKit이 해당 페이지를 load 하는 시퀀스를 분석했었다. 이번에는 페이지가 load되어 있는 상태에서 사용자가 웹페이지의 HTML Anchor를 클릭했을 때 WebKit이 새로운 페이지를 load 하는 시퀀스를 정리한다. 서론이 다소 길었다. 사실 다음 시퀀스 다이어그램이 전부다. FrameLoader::loadWithDocumentLoader() 이후의 시퀀스는 이전 기사의 FrameLoader::load(docLoader) 호출 이후의 시퀀스와 동일하다.



이미지를 클릭하면 원본 크기로 볼 수 있다.

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