KR102284630B1 - 웹브라우저의 레이아웃 엔진 메모리 공간에서의 객체와 스크립팅 엔진 메모리 공간에서의 객체 사이의 바인딩을 나타내기 위한 인터페이스 - Google Patents

Abstract

다양한 실시형태는 웹 브라우저의 레이아웃 엔진과 스크립팅 엔진 사이에 인터페이스를 제공한다. 인터페이스는 레이아웃 엔진으로부터의 객체가 스크립팅 엔진의 메모리 매니저에 의해 인식되는 것, 및 능률적이고 효율적인 방식으로 상호작용하는 것을 가능하게 한다. 하나 이상의 실시형태에 따르면, 인터페이스는 브라우저 레이아웃 엔진 객체가, 스크립팅 엔진에 네이티브한 객체로서 생성되는 것을 허용한다. 대안적으로 또는 추가적으로, 몇몇 실시형태에서, 네이티브 객체는 또한, 레이아웃 엔진과 스크립팅 엔진 사이에서 기능성을 프록시하도록 구성된다.

Description

웹브라우저의 레이아웃 엔진 메모리 공간에서의 객체와 스크립팅 엔진 메모리 공간에서의 객체 사이의 바인딩을 나타내기 위한 인터페이스{INTERFACE FOR REPRESENTING BINDINGS BETWEEN OBJECTS IN A WEB BROWSER'S LAYOUT ENGINE MEMORY SPACE AND OBJECTS IN A SCRIPTING ENGINE MEMORY SPACE}

시간이 지남에 따라, 웹 페이지는 호스트 환경에서 렌더링되고 있는 다큐먼트를 변경하고/하거나 수정할 수 있는 복잡한 동작을 포함하도록 진화하였다. 이들 복잡한 동작 중 몇몇을 달성하기 위해, 웹 프로그래머는 호스트 환경 내에서 그리고 렌더링되고 있는 다큐먼트와 함께 작동하는 스크립팅 언어를 활용할 수 있다. 많은 호스트 환경은, 다큐먼트의 렌더링을 용이하게 하는 레이아웃 엔진과 관련 웹 페이지에 포함되는 스크립트를 실행하는 스크립팅 엔진을 구별한다. 스크립팅 엔진에서 실행하는 스크립트는 레이아웃 엔진에서 렌더링되고 있는 다큐먼트뿐만 아니라, 다큐먼트 내의 객체 및/또는 엘리먼트에 액세스하도록 디자인될 수 있다. 몇몇 경우에서, 레이아웃 엔진이 다큐먼트 객체 모델(Document Object Model; DOM)과 같은 표준화된 다큐먼트 액세스를 지원하면, 웹 프로그래머는 이 모델에 기초하여 다큐먼트 및 그것의 엘리먼트를 조작할(manipulate) 스크립트를 작성할 수 있다.

레이아웃 엔진 및 스크립팅 엔진은 서로 상이한 기능성을 제공하며, 그에 따라, 이들은 통상적으로, 어떤 레벨에서, 별개의 모듈에 상주한다. 이것은, 소프트웨어 및/또는 하드웨어 컴포넌트 간의 간단한 논리적 분리에서부터 더 복잡한 분리까지의 범위에 이를 수 있다. 종종, 이들 엔진은, 서로 통신하는 별개의 및/또는 관련된 소프트웨어 모듈에 상주한다. 이 분리의 하나의 이점은, 레이아웃 엔진이 다수의 스크립팅 엔진을 더 쉽게 지원하는 것을 이 분리가 가능하게 한다는 것이다. 그러나, 레이아웃 엔진이, 어떤 레벨에서, 스크립팅 엔진으로부터 분리되기 때문에, 모듈 사이의 통신 메커니즘은, 모듈 사이에서 노출될 수 있는 것을 종종 제한하고, 런타임 성능에 악영향을 끼칠 수 있으며, 의도치 않은 메모리 관리 이슈를 도입할 수 있다.

이 개요는 하기의 상세한 설명에서 더 설명되는 개념의 선택을 간소화된 형태로 소개하기 위해 제공된다. 이 개요는 청구되는 주제의 주요 피쳐(feature)나 또는 본질적인 피쳐를 식별하도록 의도된 것이 아니며, 청구되는 주제의 범위를 제한하는데 사용되도록 의도된 것도 아니다.

다양한 실시형태는 웹 브라우저의 레이아웃 엔진과 스크립팅 엔진 사이에 인터페이스를 제공한다. 인터페이스는 레이아웃 엔진으로부터의 객체가 스크립팅 엔진의 메모리 매니저에 의해 인식되는 것을 가능하게 하고 그리고 능률적이고 효율적인 방식으로 스크립팅 엔진과 상호작용하는 것을 가능하게 한다. 하나 이상의 실시형태에 따르면, 인터페이스는 브라우저 객체가, 스크립팅 엔진에 네이티브한(native) 객체로서 생성되는 것을 허용한다. 대안적으로 또는 추가적으로, 몇몇 실시형태에서, 네이티브 객체(native object)는 또한, 레이아웃 엔진과 스크립팅 엔진 사이에서 기능성을 프록시하도록(proxy) 구성된다.

몇몇 실시형태에서, 웹 브라우저의 레이아웃 엔진과 스크립팅 엔진 사이의 바인딩(binding)은, 레이아웃 엔진과 스크립팅 엔진 사이의 통합된 프로그래밍 액세스를 가능하게 하도록 구성되는 피쳐를 포함할 수 있다. 그 피쳐는 메모리 관리를 향상시키고, 레이아웃 엔진과 스크립팅 엔진 사이의 직접 액세스(direct access)를 가능하게 하고, 및/또는 이중성 객체(dual nature object)의 가변성(mutability)을 가능하게 하도록 구성될 수 있다.

다양한 실시형태는 또한, 별개의 도메인에 상주하는 스크립팅 엔진 사이의 보안 상호작용을 가능하게 하는 보안 모델을 제공할 수 있다. 몇몇 경우에서, 객체 액세스를 방지하기 위해 및/또는 타입 시스템 정보(type system information)에 대한 액세스를 제한하기 위해 보호수단(protection)이 활용될 수 있다. 대안적으로 또는 추가적으로, 도메인 교차 액세스 기능성(cross-domain access functionality)을 포함하는 함수는 안전한 것으로 마킹될 수 있다. 몇몇 실시형태에서, 서브 윈도우 프록시는 다수의 도메인에 걸친 보안 트랜잭션을 한 윈도우와 관련되는 하나 이상의 서브 객체로 제공할 수 있다.

유사한 피쳐를 참조하기 위해 도면 전체에 걸쳐 동일한 도면번호가 사용된다.
도 1은, 하나 이상의 실시형태에 따른, 본원에서 설명되는 다양한 원리가 활용될 수 있는 동작 환경을 예시한다.
도 2는 하나 이상의 실시형태에 따른 관계 다이어그램(relationship diagram)을 예시한다.
도 3은 하나 이상의 실시형태에 따른 방법에서의 단계를 설명하는 흐름도이다.
도 4는 하나 이상의 실시형태에 따른 메모리 모델에서의 객체 관계(object relationship)를 예시한다.
도 5는 하나 이상의 실시형태에 따른 예시적인 데이터 구조를 예시한다.
도 6은 하나 이상의 실시형태에 따른 예시적인 데이터 구조를 예시한다.
도 7은 하나 이상의 실시형태에 따른 방법에서의 단계를 설명하는 흐름도이다.
도 8은 하나 이상의 실시형태에 따른 예시적인 바인딩 모듈을 예시한다.
도 9는 하나 이상의 실시형태에 따른 방법에서의 단계를 설명하는 흐름도이다.
도 10은 하나 이상의 실시형태에 따른 관계 다이어그램을 예시한다.
도 11은 하나 이상의 실시형태에 따른 방법에서의 단계를 설명하는 흐름도이다.
도 12는 하나 이상의 실시형태에 따른 방법에서의 단계를 설명하는 흐름도이다.
도 13은 하나 이상의 실시형태에 따른 방법에서의 단계를 설명하는 흐름도이다.
도 14는 하나 이상의 실시형태에 따른 방법에서의 단계를 설명하는 흐름도이다.
도 15는 하나 이상의 실시형태에 따른 프로세스 다이어그램(process diagram)을 예시한다.
도 16은 하나 이상의 실시형태에 따른 방법에서의 단계를 설명하는 흐름도이다.
도 17은 하나 이상의 실시형태에 따른 예시적인 보안 모듈을 예시한다.
도 18은 하나 이상의 실시형태에 따른 방법에서의 단계를 설명하는 흐름도이다.
도 19는 하나 이상의 실시형태에 따른 관계 다이어그램을 예시한다.
도 20은 하나 이상의 실시형태에 따른 예시적인 확장 IDL 파일(extended IDL file)을 예시한다.
도 21은 하나 이상의 실시형태에 따른 방법에서의 단계를 설명하는 흐름도이다.
도 22는 하나 이상의 실시형태에 따른 메모리 모델에서의 예시적인 객체 관계를 예시한다.
도 23은 하나 이상의 실시형태에 따른 예시적인 데이터 구조를 예시한다.
도 24는 하나 이상의 실시형태에 따른 예시적인 데이터 구조를 예시한다.
도 25는 하나 이상의 실시형태에 따른 방법에서의 단계를 설명하는 흐름도이다.
도 26은 하나 이상의 실시형태를 구현하기 위해 활용될 수 있는 예시적인 시스템을 예시한다.

개관

다양한 실시형태는 웹 브라우저의 레이아웃 엔진과 스크립팅 엔진 사이에 인터페이스를 제공한다. 통상적으로, 예시적인 프로세스에 대한 개관으로서, 유저는 웹 브라우저를 열어서 웹 페이지를 내비게이팅할 것이다. 웹 페이지는, 웹 브라우저의 어떤 버전이 실행 중에 있는지를, 예컨대 어떤 피쳐가 지원되는지를 결정하도록 구성될 수 있다. 웹 페이지가 렌더링되고 있는 동안의 몇몇 지점에서, 예컨대 기능성(예를 들면, IDispatchEx)에 대한 동적 요청을 통해, 또는 파싱되고 있는 스크립트를 통해, 스크립팅 엔진이 생성될 수 있다. 몇몇 실시형태에서, 스크립팅 엔진의 생성 및/또는 초기화는, 타입 스트림을 등록하는 것, 스크립팅 엔진과 웹 브라우저의 레이아웃 엔진 사이에 다양한 관계를 확립하는 것뿐만 아니라, 다양한 관계와 관련되는 바인딩을 구축하는 것을 포함할 수 있는데, 이것은 하기에서 더 상세히 설명될 것이다. 몇몇 경우에, 유저는 제2 웹 페이지로 내비게이팅할 수도 있다. 제2 웹 페이지로 이행할 때, 웹 브라우저는 제2 페이지와 관련되는 새로운 스크립팅 엔진을 생성하도록, 제1 스크립팅 엔진으로부터 새로운 스크립팅 엔진으로 객체를 옮기도록, 그리고 그 다음 제1 스크립팅 엔진을 닫도록 구성될 수 있다.

인터페이스 및 바인딩은 레이아웃 엔진으로부터의 다양한 객체가 스크립팅 엔진의 메모리 매니저에 의해 인식되는 것을 가능하게 하고 그리고 능률적이고 효율적인 방식으로 스크립팅 엔진과 상호작용하는 것을 가능하게 한다. 하나 이상의 실시형태에 따르면, 인터페이스는 브라우저 객체가, 스크립팅 엔진에 네이티브한 객체로서 생성되는 것을 허용한다. 대안적으로 또는 추가적으로, 몇몇 실시형태에서, 네이티브 객체는 또한, 레이아웃 엔진과 스크립팅 엔진 사이에서 기능성을 프록시하도록 구성된다.

몇몇 실시형태에서, 웹 브라우저의 레이아웃 엔진과 스크립팅 엔진 사이의 바인딩은, 레이아웃 엔진과 스크립팅 엔진 사이의 통합된 프로그래밍 액세스를 가능하게 하도록 구성되는 피쳐를 포함할 수 있다. 그 피쳐는 메모리 관리를 향상시키고, 레이아웃 엔진과 스크립팅 엔진 사이의 직접 액세스를 가능하게 하고, 및/또는 이중성 객체의 가변성(mutability)을 가능하게 하도록 구성될 수 있다.

다양한 실시형태는 또한, 별개의 도메인에 상주하는 스크립팅 엔진 사이의 보안 상호작용을 가능하게 하는 보안 모델을 제공할 수 있다. 몇몇 경우에서, 객체 액세스를 방지하기 위해 및/또는 타입 시스템 정보에 대한 액세스를 제한하기 위해 보호수단이 활용될 수 있다. 대안적으로 또는 추가적으로, 도메인 교차 액세스 기능성을 포함하는 함수는 안전한 것으로 마킹될 수 있다. 몇몇 실시형태에서, 서브 윈도우 프록시는 다수의 도메인에 걸친 보안 트랜잭션을 한 윈도우와 관련되는 하나 이상의 서브 객체로 제공할 수 있다.

하나 이상의 실시형태에서, 인터페이스 정의 언어(Interface Definition Language; IDL)에 대한 확장은 레이아웃 엔진 및 스크립팅 엔진의 직접적인 통합을 가능하게 할 수 있다. 몇몇 실시형태에서, 확장 IDL은 레이아웃 엔진과 스크립팅 엔진을 연결하도록(bridge) 구성되는 코드의 생성을 가능하게 할 수 있다. 대안적으로 또는 추가적으로, 객체와 그들의 관련 API 사이의 계층적 관계가 확장 IDL을 사용하여 설명될 수 있다. 몇몇 실시형태에서, 확장 IDL은 객체 및/또는 관련 API의 속성을 설명하는 구문(syntax)을 포함할 수 있다.

스크립팅 엔진에서 표현되는 레이아웃 엔진 객체와 관련되는 스크립팅 엔진 메모리 공간에서 표현되는 적어도 몇몇 특성 객체에 대한 스크립팅 엔진 직접 액세스를 유효하게 가능하게 하기 위해, 몇몇 실시형태는 레이아웃 엔진과 스크립팅 엔진 사이에 인터페이스를 제공한다. 몇몇 경우에서, 스크립팅 엔진은, 스크립팅 엔진 도메인 내에 포함되는 기능성을 사용하여 및/또는 레이아웃 엔진 도메인 안으로 넘어가지 않으면서 스크립팅 엔진에서 표현되는 특성 객체에 액세스한다.

후속하는 논의에서, "동작 환경"으로 명칭이 부여된 섹션이 제공되어 하나 이상의 실시형태가 활용될 수 있는 하나의 환경을 설명한다. 이것에 후속하여, "객체 통합 및 메모리 모델"로 명칭이 부여된 섹션은, 웹 브라우저의 레이아웃 엔진으로부터의 객체가 스크립팅 엔진의 메모리 매니저에 의해 인식되는 것을 가능하게 하며, 추가적으로 엔진 사이의 능률적인 상호작용을 가능하게 하는 아키텍쳐를 설명한다. 이것 다음에, "직접적인 시스템 통합"으로 명칭이 부여된 섹션은, 레이아웃 엔진과 스크립팅 엔진 사이의 직접적인 시스템 통합을 가능하게 하는 제공된 피쳐를 설명한다. 다음에, "보안 모델"로 명칭이 부여된 섹션은, 하나 이상의 실시형태에 따라 보안이 어떻게 강화될 수 있는지를 설명한다. 이것에 후속하여, "인터페이스 정의 언어 통합"으로 명칭이 부여된 섹션은, 객체 및 그들의 관련 API 및/또는 속성의 계층을 정의하기 위해 인터페이스 정의 언어가 어떻게 확장될 수 있는지를 설명한다. 다음에, "스크립팅 엔진과 레이아웃 엔진 사이의 대안적 액세스"로 명칭이 부여된 섹션은, 스크립팅 엔진 도메인 내에서 설명되는 레이아웃 엔진 객체에 대한 스크립팅 엔진의 직접적이고 효율적인 액세스를 가능하게 하는 대안적인 인터페이스를 설명한다. 이것 다음에, "기타 고려사항(other consideration)"으로 명칭이 부여된 섹션은 추가적인 고려사항 및/또는 피쳐를 설명한다. 마지막으로, "예시적인 시스템"으로 명칭이 부여된 섹션은 하나 이상의 실시형태를 구현하기 위해 활용될 수 있는 예시적인 시스템을 설명한다.

하기에 설명될 다양한 실시형태의 개관을 제공하였지만, 이제 하나 이상의 실시형태가 구현될 수 있는 예시적인 동작 환경을 고려한다.

동작 환경

도 1은 하나 이상의 실시형태에 따른 동작 환경을 일반적으로 100에서 예시한다. 환경(100)은, 하나 이상의 프로세서(104), 하나 이상의 컴퓨터 판독가능 저장 매체(106) 및 컴퓨터 판독가능 저장 매체 상에 상주하며 프로세서(들)에 의해 실행가능한 하나 이상의 애플리케이션(108)을 구비하는 컴퓨팅 디바이스(102)를 포함한다. 컴퓨터 판독가능 저장 매체는, 비제한적인 예로서, 컴퓨팅 디바이스와 통상적으로 관련되는 모든 형태의 휘발성 및 불휘발성 메모리 및/또는 저장 매체를 포함할 수 있다. 이러한 매체는 ROM, RAM, 플래시 메모리, 하드 디스크, 착탈식 매체 등을 포함할 수 있다. 컴퓨팅 디바이스의 하나의 특정한 예는 도 21에서 도시되며 하기에서 설명된다.

또한, 컴퓨팅 디바이스(102)는 웹 브라우저(110) 형태의 소프트웨어 애플리케이션을 포함한다. 임의의 적절한 웹 브라우저가 사용될 수 있는데, 그 예는 본 문서 및 다른 문서들의 양수인으로부터 입수가능하다. 브라우저(110)는 별개의 모듈, 예컨대 레이아웃 엔진(112) 및 스크립팅 엔진(들)(114)을 자신의 기능성에 포함하거나 또는 자신의 기능성에서 활용할 수 있다. 레이아웃 엔진(112)은, 다른 것들 중에서도, 마크업 컨텐츠(marked up content)(예컨대 HTML, XML, 이미지 파일 등) 및 포맷팅 정보(예컨대 CSS, XSL 등)를 프로세싱하여 포맷팅된 컨텐츠를 렌더링할 수도 있고/있거나 디스플레이할 수도 있다. 스크립팅 엔진(들)(114)은 스크립팅 언어 코드를 프로세싱하여 실행할 수 있는 기능성을 포함한다. 브라우저(110)에 통합되는 것으로 예시되지만, 스크립팅 엔진(들)(114)은 독립형 컴포넌트로서 구현될 수 있다는 것이 인식되고 이해되어야 한다. 대안적으로 또는 추가적으로, 스크립팅 엔진(들)(114)은 애플리케이션(108)의 일부로서 및/또는 시스템의 오퍼레이팅 시스템의 일부로서 구현될 수 있다.

컴퓨팅 디바이스(102)는 또한 바인딩 모듈(116)을 포함하는데, 바인딩 모듈(116)은, 하기에 더 상세히 설명되는 바와 같이, 레이아웃 엔진(112) 및 스크립팅 엔진(114)이 서로 바인딩하고(bind), 인터페이싱하고, 및/또는 통신하는 것을 가능하게 하는 기능성을 포함한다.

게다가, 컴퓨팅 디바이스(102)는 또한 보안 모듈(118)을 포함하는데, 보안 모듈(118)은, 하기에서 설명되는 바와 같이, 도메인 교차 보안(cross-domain security)이 스크립팅 엔진(114) 및/또는 레이아웃 엔진(112)을 이용하여 강화되는 것뿐만 아니라, 동일한 출처(origin)의 요청에 대해 효율성이 향상되는 것을 가능하게 하는 기능성을 포함한다. 몇몇 실시형태에서, 보안 모듈(118)은, 하기에서 추가로 설명되는 바와 같이, 레이아웃 엔진(112) 및/또는 스크립팅 엔진(114) 안으로 통합되는 및/또는 레이아웃 엔진(112) 및/또는 스크립팅 엔진(114)에 의해 활용되는 피쳐 및/또는 기능성을 포함한다.

하나 이상의 실시형태에서, 컴퓨팅 디바이스(102)는 하나 이상의 확장 인터페이스 정의 언어(IDL) 파일(120)을 또한 포함한다. 확장 IDL 파일(120)은, 하기에서 추가로 설명되는 바와 같이, 객체 및 그들의 관련 애플리케이션 프로그래밍 인터페이스(Application Programming Interface; API)에 대한 추가적인 설명 및/또는 정의를 가능하게 하는 IDL에 대한 다양한 확장을 포함할 수 있다.

게다가, 환경(100)은 인터넷과 같은 네트워크(122), 및 하나 이상의 웹 사이트(124)를 포함하는데, 컨텐츠는 이 웹 사이트(124)로부터 수신될 수 있고 이 웹 사이트(124)로 전송될 수 있다. 이러한 컨텐츠는 브라우저(110)에 의해 통상적으로 수신되어 프로세싱되는 임의의 타입의 컨텐츠를 포함할 수 있다.

컴퓨팅 디바이스(102)는 임의의 적절한 컴퓨팅 디바이스, 예컨대, 비제한적인 예로서, 데스크탑 컴퓨터, 휴대형 컴퓨터, 개인 정보 휴대 단말(personal digital assistant; PDA)과 같은 핸드헬드 컴퓨터, 셀 폰 등으로서 구체화될 수 있다.

예시적인 동작 환경을 설명하였지만, 이제, 웹 브라우저의 레이아웃 엔진이 하나 이상의 스크립팅 엔진과 효율적이고 능률적인 방식으로 인터페이싱하는 것을 가능하게 하는 객체 통합 및 메모리 모델의 논의를 고려한다.

객체 통합 및 메모리 모델

하나 이상의 실시형태에 따르면, 웹 브라우저의 레이아웃 엔진과 스크립팅 엔진 사이의 인터페이스는 레이아웃 엔진으로부터의 객체가 스크립팅 엔진 메모리 공간 안으로 통합되는 것을 가능하게 한다. 예를 들면, 몇몇 실시형태에서, 스크립팅 엔진 메모리 공간에 네이티브한 객체는 레이아웃 엔진 메모리 공간과 관련되는 객체에 바인딩될 수 있다. 레이아웃 엔진 객체에 액세스하기 위해, 스크립팅 엔진은 스크립팅 엔진 메모리 공간에 네이티브한 객체에 액세스할 수 있다. 네이티브 객체는 또한 레이아웃 엔진과 스크립팅 엔진 사이의 기능성을 프록시하도록 구성될 수 있다.

한 예로서, 하나 이상의 실시형태에 따른 스크립팅 엔진(스크립팅 엔진 측)과 레이아웃 엔진(레이아웃 엔진 측) 사이의 관계를 묘사하는 관계 블록도(200)를 예시하는 도 2를 고려한다. 스크립팅 엔진 측은 세 개의 기능적 블록: 유저 코드(스크립트 프로그램)(202), 동적 특성(204) 및 자바스크립트 타입 시스템(JavaScript Type System)(206)을 포함한다. 레이아웃 엔진 측은 두 개의 기능적 블록: 본원에서 다큐먼트 객체 모델(DOM) 코드로 예시되는 다큐먼트 관리 코드(208), 및 속성 스토리지(엘리먼트)(210)를 포함한다. 이 예가 스크립팅 엔진을 자바스크립트 엔진으로서, 그리고 레이아웃 엔진을, 자신의 표준화된 다큐먼트 액세스로서 DOM을 포함하는 것으로서 예시하지만, 임의의 타입의 스크립트 언어 및/또는 표준화된 다큐먼트 액세스가 활용될 수 있다는 것이 인식되고 이해되어야 한다.

예시되고 설명된 실시형태에서, 스크립팅 엔진과 레이아웃 엔진 사이에 하나 이상의 트램펄린(trampoline)(212)이 논리적으로 개재(interpose)된다. 하기에서 명백하게 되는 바와 같이, 트램펄린은 스크립팅 엔진 및 레이아웃 엔진이 서로 통신하고 서로 간에 기능성을 호출하는 것을 가능하게 하도록 기능한다.

예시되고 설명된 실시형태에서, 유저 스크립트 코드(202)는 스크립팅 엔진에 의해 해석되어 실행될 수 있는 스크립트 코드를 포함하는데, 이것은 당업자에 의해 인식될 수 있을 것이다. 몇몇 실시형태에서, 유저 스크립트 코드(202)는 웹 페이지로부터의 스크립트 코드를 포함할 수 있다. 다른 것들 중에서도, 유저 스크립트 코드(202)는, 특정 웹 페이지를 렌더링하는 호스트 환경과의 상호작용을 가능하게 하는 스크립트를 포함할 수 있다. 스크립트 코드는 HTML 페이지에 임베딩될 수 있거나 또는 HTML 페이지로부터 포함될 수 있으며 웹 페이지의 DOM과 상호작용할 수 있다. 통상적으로, 스크립트 코드의 간단한 사용은, 비제한적인 예로서, 사이즈, 위치 및 속성에 대한 프로그램적 제어를 갖는 새로운 윈도우를 열거나 팝업하는 것; 웹 형태의 입력 값을, 서버에 제출되기 이전에 그 값이 수용가능하다는 것을 보장하기 위해, 검증하는(validating) 것; 및 마우스 커서가 이미지 위에서 움직임에 따라 이미지를 변경하는 것을 포함한다.

동적 특성(204)은 스크립팅 언어 및/또는 스크립팅 엔진과 관련되는 객체의 특성을 동적으로 설정하고/하거나 변경하는 능력을 가능하게 한다. 스크립팅 언어 객체의 특성을 설정 및/또는 변경하는 것 외에, 동적 특성(204)은 레이아웃 엔진의 객체, 예컨대, 비제한적인 예로서, 다큐먼트 객체 관리 코드(208)에 포함되고/되거나 다큐먼트 객체 관리 코드(208)와 관련되는 다양한 DOM 객체와 관련되는 특성을 동적으로 설정하고/하거나 변경하는 능력을 포함한다. 대안적으로 또는 추가적으로, 동적 특성(204)은 유저 코드(202)의 실행을 통해 생성되는 특성, 프로토타입, 및/또는 객체를 포함할 수 있다. 동적 특성(204)은, 그들의 관련 객체(들)에 무관하게, 스크립팅 엔진을 통해 관리되는 메모리에 완전히 저장될 수 있다는 것을 유의해야 한다.

하나 이상의 실시형태에서, 타입 시스템(206)은, 값 및/또는 객체가 적절히 액세스될 수 있도록, 타입을 객체 및/또는 값과 관련시키도록 구성된다. 예를 들면, 타입 시스템은, 객체 및/또는 값에 대해 정확한 프로토타입이 사용되는 것을 보장할 수 있다. 대안적으로 또는 추가적으로, 타입 시스템(206)은 객체 및/또는 값의 타입을 동적으로 지정하도록 구성될 수 있다. 몇몇 실시형태에서, 타입 시스템(206)은 다큐먼트 객체 관리 코드(208)의 하나 이상의 객체와 관련되는 타입 시스템 정보를 포함할 수 있다.

레이아웃 엔진 측 상에서, 다큐먼트 관리 코드(208)는, 레이아웃 엔진이 다큐먼트를 생성하고, 관리하고, 및/또는 렌더링하는 것을 가능하게 하는 기능성을 포함한다. 다큐먼트 관리 코드(208)는 또한, 다큐먼트의 또는 다큐먼트에 대한 외부 노출 및/또는 액세스를 가능하게 할 수 있다. 예를 들면, 웹 페이지는, 스크립팅 엔진에서의 실행시, 다큐먼트에 대해 상호작용적 피쳐를 프로그래밍하기 위해 다큐먼트의 외부 액세스를 사용할 수 있는 유저 스크립트 코드를 사용할 수 있다. 예시되고 설명된 실시형태에서, 동적 특성(204)은 다큐먼트 관리 코드(208)의 동적 특성을 포함하고 스크립팅 엔진 메모리 공간에 저장된다. 역으로, 속성 스토리지(210)는, 본원에서 예시되는 바와 같이, 레이아웃 엔진 메모리 공간을 활용한다. 속성 스토리지(210)는, 다큐먼트 관리 코드(208)와 관련되는 정적 속성 및/또는 엘리먼트를 포함할 수 있다.

하나 이상의 실시형태에서, 스크립팅 엔진 측과 레이아웃 엔진 측 사이에 논리적으로 개재되는 트램펄린(들)(212)은, 스크립팅 엔진과 레이아웃 엔진 사이의 적어도 하나의 브릿지를 나타낸다. 예시된 바와 같이, 트램펄린(212)은 스크립팅 엔진과 레이아웃 엔진 사이에 논리적으로 위치되며, 적어도 몇몇 실시형태에서, 하기에서 추가적으로 논의되는 바와 같이, 스크립팅 엔진 메모리 공간의 객체로부터의 호출을 레이아웃 엔진 메모리 공간의 관련 객체로 리다이렉트(redirect)하도록 구성될 수 있다. 따라서, 트램펄린은, 스크립팅 엔진이 스크립팅 엔진에 네이티브한 객체와 관련되는 함수를 직접적으로 호출할 수 있지만, 실제 작업부하 실행을 위해 호출을 레이아웃 엔진으로 리다이렉트되게 할 수 있는 리다이렉션 메커니즘(redirection mechanism)으로서 기능한다. 이러한 리다이렉션 메커니즘은, 인터페이스 포인터, ID(identification) 값 등을 요청할 필요 없이, 두 개의 엔진이 통신하는 것을 가능하게 한다. 따라서, 스크립팅 엔진 및 레이아웃 엔진은 이제 더 밀접하게(tightly) 바인딩되고 엔진 교차 객체(cross-engine object)에 대해 더 넓은 범위로 액세스할 수 있다.

한 예로서, 하나 이상의 실시형태에 따른 방법에서의 단계를 설명하는 흐름도를 예시하는 도 3을 고려한다. 방법은 임의의 적절한 하드웨어, 소프트웨어, 펌웨어, 또는 이들의 조합에 의해 수행될 수 있다. 적어도 몇몇 실시형태에서, 방법의 양태는 시스템, 예컨대 도 1 및 도 2에서 예시되는 시스템에 의해 수행된다.

단계 300은 적어도 하나의 트램펄린 함수를 생성한다. 트램펄린 함수는 임의의 적절한 방식으로, 예컨대 C++ 소스 및 헤더 파일을 통해 생성될 수 있는데, 하기의 "인터페이스 정의 언어 통합"으로 명칭이 부여된 섹션에서 추가로 설명된다. 단계 302는 스크립팅 엔진과 레이아웃 엔진 사이에 트램펄린 함수를 논리적으로 개재한다. 두 엔진 사이에 트램펄린 함수를 개재하는 것은, 엔진에 걸쳐 기능성을 호출하는 능력을 가능하게 한다. 트램펄린 함수를 사용하여, 단계 304는 스크립팅 엔진과 레이아웃 엔진 간의 직접 액세스를 가능하게 한다. 예를 들면, 트램펄린 함수는, 상기에서 그리고 "동적 타입 시스템 다이렉트 함수"로 명칭이 부여된 섹션의 하기에서 추가로 설명되는 바와 같이, 스크립팅 엔진으로부터의 호출이, 적절하다면, 레이아웃 엔진으로 리다이렉트되는 것을 가능하게 하도록 구성될 수 있다.

스크립팅 엔진, 레이아웃 엔진, 및 트램펄린 함수 사이의 관계를 설명하였지만, 이제, 스크립팅 엔진 메모리 공간("자바스크립트"로 지정됨) 및 레이아웃 엔진 메모리 공간(컴포넌트 객체 모델(Component Object Model; COM) 기반의 레이아웃 엔진을 나타내기 위해 "COM" 으로 지정됨)을 포함하는 메모리 모델에서의 객체 관계를 예시하는 도 4를 고려한다.

레이아웃 엔진 메모리 공간은, 다른 객체, 예컨대 CBase 객체(404), 내부 레이아웃 엔진 객체(406) 및 액티브X/BHO 객체(408)(여기서 "BHO"는 "브라우저 헬퍼 객체(Browser Helper Object)"를 나타냄)에 대한 관계를 갖는 COM 기반 객체를 나타내는 CBase 객체(402)를 포함하는 다양한 객체를 포함한다.

스크립팅 엔진 메모리 공간은 다양한 객체, 예컨대 루트 객체(410), 객체 그래프 객체(412), 및 var 객체(414, 416)를 포함한다. 루트 객체(410)는, var 객체(444)가 근간으로 하거나 어태치되는(attached) 고정된 객체를 나타내고, 객체 그래프(412)는 메모리 시스템 매니저에 의해 관리되는 스크립팅 엔진 메모리 공간내의 객체의 객체 관계 그래프를 나타낸다. 스크립팅 엔진 메모리 공간은, 링크(link)(418, 420)와 같은 액세스 링크를 통해 레이아웃 엔진 메모리 공간에 액세스할 수 있고/있거나 레이아웃 엔진 메모리 공간에 바인딩된다.

예시되고 설명된 실시형태에서, 메모리 모델의 각 측은, 메모리 모델의 다른 측 상의 적어도 하나의 객체와 관련되는 적어도 몇몇 객체를 포함한다. 예를 들면, CBase 객체(404)는 링키지(linkage)(420)를 통해 var 객체(416)에 링크되고/되거나 바인딩되고, CBase 객체(402)는 링키지(418)를 통해 var 객체(414)에 마찬가지로 링크되고/되거나 바인딩된다. 하기에서 추가로 설명되는 바와 같이, 객체를 링크하고/하거나 바인딩하기 위해, 다양한 메커니즘이 사용될 수 있다.

몇몇 실시형태에서, CBase 객체(402, 404)는, 요청을 스크립팅 엔진으로부터 CBase 객체(402, 404)로 프록시하거나 또는 "포워딩"하도록 구성되는 다이렉트 함수 및/또는 타입 동작(type operation)을 통해 액세스 될 수 있는 기능성에 대한 실제 구현예를 포함한다. 예를 들면, 스크립팅 엔진에서 실행하는 스크립트는, 스크립팅 엔진 메모리 공간에 네이티브한 var 객체(414, 416)에 액세스할 수 있다. 스크립트는 관련 CBase 객체뿐만 아니라 관련 링키지도 반드시 알고 있어야 할 필요는 없다. 대신, 스크립트는 소정의 기능성 및 정보와 관련되는 호출 또는 요청에 액세스하고, 그 호출 또는 요청을 요청하고, 및/또는 호출 또는 요청을 하기 위한 네이티브 객체로서 var 객체에 액세스할 수 있다. 그 다음, var 객체(414, 416)와 관련될 수 있는 다이렉트 함수 및/또는 타입 동작은, 호출 또는 요청의 실제 실행을 위해 호출을 관련 CBase 객체로 프록시하고/하거나 포워딩하도록 구성될 수 있다. 이 관계는, 어떤 의미에서, 성질에서 이중적인 객체의 존재를 가능하게 한다. 구체적으로는, 한 객체가 레이아웃 엔진에 존재할 수 있고 스크립팅 엔진에서 생성되어 유지되는 관련된 네이티브 표현을 가질 수 있다.

객체의 이중성을 관리하는 부분은, var 객체(416)와 같은 스크립팅 엔진의 객체와 CBase 객체(404)와 같은 레이아웃 엔진의 대응하는 객체 사이의 소위 수명 관계를 관리하는 것을 포함한다. 예를 들면, var 객체(416)가 스크립트에 의해 액티브하게 사용되고 있으면, 대응하는 CBase 객체(404)도 또한 액티브하게 사용될 것이다.

몇몇 경우에서, 메모리 관리 시스템은, "가비지 콜렉션(garbage collection)"으로도 또한 칭해지는 자동 메모리 관리를 구현할 수 있는데, 자동 메모리 관리는 메모리가 더 이상 사용되지 않는다고 결정되면 메모리의 회수를 시도한다. 가비지 수집 시스템(garbage collected system)에서의 메모리 관리의 보다 수동적인 방법은, 객체가 수동으로 고정해제될(unpinned) 때까지 가비지 컬렉터(garbage collector)가 객체 메모리 공간을 회수할 수 없도록, 객체를 고정하는(pinning) 것을 수반한다. 객체가 영구적으로 회수되면, 이중성 객체 사이의 링키지는 파괴될 수 있다. 역으로, 객체는 액티브인 것으로 다수 회 마킹될 수 있고, 따라서 잠재적인 메모리 누설을 생성하게 되는데, 다수의 액티브 마킹이 적절히 소거되지 않으면, 메모리가 회수되지 않는다는 것을 의미한다.

몇몇 실시형태에서, 무엇이 회수 가능한 객체일 수도 있는지를 식별하기 위해 가비지 컬렉터에 의해 객체 그래프, 예컨대 객체 그래프(412)가 유지될 수 있다. 객체는, var 객체의 사용을 통해, 객체 그래프, 그리고 후속하여, 가비지 컬렉터에서의 액티브 참여를 유지할 수 있다. 이 액티브 참여는, 객체가 고정되는 것을 요구하지 않고도, 객체가 자신의 수명을 유지하는 것을 가능하게 한다.

몇몇 실시형태에서, 이중성 객체와 관련되는 스크립팅 언어 객체가 생성되면, 그 아이덴티티(identity)는, 바로 아래에서 설명되는 확장 커스텀 데이터를 갖는, 본원에서 "CustomExternalObject"로 칭해지는 객체를 사용하여 레이아웃 엔진과 바인딩될 수 있다. 또한, CustomExternalObject는 관계를 가비지 컬렉터에게 노출시킬 수 있고, 따라서 한 객체가 재활용될 수 있는 때를 가비지 컬렉터가 더 정확하게 추적하는 것을 가능하게 한다.

한 예로서, 하나 이상의 실시형태에 따른 예시적인 CustomExternalObject(500)를 예시하는 도 5를 고려한다. CustomExternalObject(500)는, 생성되고 있는 스크립팅 언어 객체, 또는 var를 나타내는 객체(502)를 포함한다. 몇몇 실시형태에서, 스크립팅 언어 객체는 이중성 객체와 관련된다. 객체(502) 외에, CustomExternalObject는 복수의 포인터, 예를 들면, 다섯 개의 포인터: CBase 포인터(504), 부모 var 포인터(parent var pointer; 506), 자식 var 포인터(child var pointer; 508), 이전 var 포인터(previous var pointer; 510), 및 다음 var 포인터(next var pointer; 512)를 포함한다. CustomExternalObject에 내에 포함되는 포인터의 사용을 통해, 두 개 이상의 객체 사이의 관계가 유지될 수 있다.

더 구체적으로는, 이 특정 예에서, CBase 포인터(504)는 이중성 객체와 관련되는 레이아웃 엔진 객체를 다시 가리키는 코드 포인터이다. 이 포인터는 이중성 객체의 스크립팅 엔진 아이덴티티와 레이아웃 엔진 아이덴티티 사이에서의 액세스를 가능하게 한다. 부모 var 포인터(506)는 객체(502)의 부모 var 객체를 가리키도록 구성된다. 마찬가지로, 자식 var 포인터(508)는 객체(502)의 자식 var 객체를 가리키도록 구성된다. 이전 var 포인터(510) 및 다음 var 포인터(512)는, 예를 들면, 부모의 다섯 개의 속성 중 하나와 같은, 객체(502)의 형제(sibling)를 가리키도록 구성되는 추가적인 관계 포인터이다. 관계 포인터의 사용을 통해, 객체 관계는 가비지 컬렉터에게 노출된다. 이것은 가비지 컬렉터가 객체의 수명을 더 정확하게 관리하는 것을 가능하게 할뿐만 아니라, 객체 중 어떠한 것도 고정하는 것을 필요로 하지 않고도 이렇게 하는 것을 가능하게 한다.

이제, 확장 CustomExternalObject 내에 포함되는 관계 포인터가 하나 이상의 실시형태에 따라 어떻게 활용될 수 있는지를 예시하는 도 6을 고려한다.

도 6은 세 개의 CustomExternalObject(602, 604, 및 606)를 예시하는데, 그 각각은 스크립팅 엔진을 통해 생성되는 var 객체를 나타낸다. 각각의 CustomExternalObject는 대응하는 이중성 객체와 관련된다. 이 특정 예에서, CustomExternalObject(602, 604, 및 606)는, 레이아웃 엔진을 통해 생성된 객체와 관련된다. 예를 들면, CBase 포인터(608)는 타입 CElement를 갖는 레이아웃 엔진의 객체를 다시 가리키는 포인터를 포함하고; CBase 포인터(610)는 타입 CStyleSheet의 객체를 다시 가리키는 포인터를 포함하고; CBase 포인터(612)는 타입 CAttribute의 객체를 다시 가리키는 포인터를 포함한다.

레이아웃 엔진 객체 사이의 관계, 및 그들의 관련 CustomExternalObject(602, 604, 및 606)는, 상기에서 설명된 추가적인 관계 포인터의 사용을 통해 스크립팅 엔진 메모리 공간에서 표현될 수 있다. 예를 들면, CustomExternalObject(604)는 CustomExternalObject(602)의 자식이고, 이것은, CustomExternalObject(602)의 자식 var 포인터를 CustomExternalObject(604)로 가리키는 링키지(614)를 통해, 그리고 CustomExternalObject(604)의 부모 var 포인터를 CustomExternalObject(602)로 가리키는 링키지(616)를 통해 표현된다. 대안적으로 또는 추가적으로, 객체의 형제 관계는, 링키지(618, 620)를 통해 예시된 바와 같이 표현되고/되거나 노출될 수 있다. 이 특정한 예에서, CustomExternalObject(604)는 CustomExternalObject(602)의 자식 객체일 뿐만 아니라, 또한 CustomExternalObject(606)의 형제이기도 하다. 이와 같이, CustomExternalObject(604)의 다음 var 포인터는, 링크(618)를 이용하여 예시된 바와 같이, 자신의 바로 옆 형제인 CustomExternalObject(606)를 가리킨다. 추가적으로, CustomExternalObject(606)는, 링크(620)에 의해 또한 예시된 바와 같이, 자신의 이전의 형제인 CustomExternalObject(604)를 가리킨다. 이 다차원적이고 이중적으로 연결된 리스트의 사용을 통해, 객체는, 객체의 전체가 고정되는 것을 요구하지 않고도, 스크립팅 엔진 메모리 매니저에게 노출될 수 있다. 몇몇 실시형태에서, 메모리 매니저로부터의 의도하지 않은 파괴 및/또는 재활용으로부터 메인 객체를 묶어 두기 위해, 헤드 또는 메인 객체가 메모리에서 고정될 수 있다.

추가적인 객체가, 예컨대 이중으로 링크된 리스트를 통해, 메인 객체를 근거로 할 수 있고, 따라서 객체가 영구적으로 재활용되는 것에 대해 약간의 보호를 강화하게 된다. 예를 들면, 객체가 생성될 때, 객체는 자신이 메모리에 고정되어야 하는지, 또는 다른 객체에 근거해야 하는지를 결정하기 위해 함수를 호출할 수 있다. 객체가 어떤 객체에 근거를 둬야 한다는 것이 결정되면, 관련된 관계 포인터가, 예컨대 객체 사이의 부모/자식 관계를 셋업하는 함수, 또는 객체 사이의 형제 관계를 셋업하는 함수를 통해, 그에 맞게 설정될 수 있다.

몇몇 실시형태에서, 레이아웃 엔진은 CustomExternalObject를 생성하고 그 객체를 스크립팅 엔진으로 전달할 수 있다. 예를 들면, 레이아웃 엔진은 스크립팅 엔진에 의해 호출가능하도록 구성되는 API를 지원할 수 있다. API 호출의 실행을 통해, 레이아웃 엔진은, 스크립팅 엔진 메모리 공간에 네이티브한 적어도 하나의 CustomExternalObject를 생성하고, 스크립팅 엔진이 레이아웃 엔진에 액세스하는 것을 가능하게 하는 정보를 CustomExternalObject(들)에 포함시키고, 호출하는 스크립팅 엔진으로 CustomExternalObject(들)를 리턴할 수 있다. 대안적으로 또는 추가적으로, API는, CustomExternalObject 내에서 지원되는 이중으로 링크된 리스트 안으로 엘리먼트 및/또는 객체가 삽입되는 및/또는 그 리스트로부터 엘리먼트 및/또는 객체가 제거되는 능력을 지원하도록 구성될 수 있다.

도 7은 하나 이상의 실시형태에 따른 방법에서의 단계를 설명하는 흐름도이다. 방법은 임의의 적절한 하드웨어, 소프트웨어, 펌웨어, 또는 이들의 조합에 의해 수행될 수 있다. 적어도 몇몇 실시형태에서, 방법의 양태는, 도 1의 브라우저(110) 및/또는 레이아웃 엔진(112)과 같은 컴퓨팅 디바이스 상에서 실행하는 적절히 구성된 객체 통합 및 메모리 모델 소프트웨어에 의해 수행된다.

단계 700은 레이아웃 엔진 객체를 생성한다. 레이아웃 엔진 객체의 생성은 임의의 적절한 방식으로, 예컨대 API 호출을 통해, 기동시에, 메시지 및/또는 이벤트의 수신을 통해, 등을 통해 수행될 수 있다. 대안적으로 또는 추가적으로, 레이아웃 엔진 객체는, 레이아웃 엔진 애플리케이션에 관계없는 레이아웃 엔진에 의해 생성되는 객체, 예컨대 레이아웃 엔진에 의해 렌더링되고 있는 다큐먼트, 다큐먼트의 엘리먼트 등일 수 있다. 단계 702는 스크립팅 언어 객체를 생성한다. 임의의 적절한 객체, 예컨대 상기에서 설명된 바와 같은 CustomExternalObject가 생성될 수 있다. 스크립팅 언어 객체는, 스크립팅 언어의 네이티브 메소드(native method)를 통해 액세스가능한, 스크립팅 엔진 메모리 공간에 네이티브한 임의의 객체를 포함한다. 대안적으로 또는 추가적으로, 스크립팅 엔진에 네이티브한 객체는 스크립팅 엔진의 메모리 매니저에 의해 관리되는 임의의 객체를 포함할 수 있다.

단계 704는 레이아웃 엔진 객체를 스크립팅 언어 객체에 바인딩한다. 임의의 적절한 방법이 활용될 수 있는데, 이들의 예는 상기에서 그리고 하기에서 제공된다.

객체 통합 및 대응하는 메모리 모델을 고려하였지만, 이제, 하나 이상의 실시형태에 따라 직접적인 시스템 통합을 가능하게 하는 피쳐의 논의를 고려한다.

직접적인 시스템 통합

몇몇 실시형태에서, 웹 브라우저의 레이아웃 엔진과 스크립팅 엔진 사이의 바인딩은, 프로그래머가 통합된 방식으로 이중성 객체의 각 측면에 액세스하는 것을 가능하게 하는 것과 같이, 레이아웃 엔진과 스크립팅 엔진 사이의 통합된 프로그래밍 액세스를 가능하게 하는 피쳐를 포함할 수 있거나 또는 다르게는 그 피쳐를 활용할 수 있다. 그 피쳐는 메모리 관리를 향상시키고, 레이아웃 엔진과 스크립팅 엔진 사이의 직접 액세스를 가능하게 하고, 및/또는, 이중성 객체, 예컨대 상기에서 설명된 이중성 객체의 가변성을 가능하게 할 수 있다.

도 8은, 하나 이상의 실시형태에 따른, 예를 들면, 도 1의 바인딩 모듈(116)과 같은 바인딩 모듈에 포함되는 피쳐의 확대도를 예시한다. 몇몇 실시형태에서, 바로 아래에서 설명되는 피쳐는 원활한(seamless) 방식으로 레이아웃 엔진 및 스크립팅 엔진을 통합하도록 디자인되는 아키텍쳐의 일부일 수 있다. 도 8이 피쳐 및/또는 모듈의 조합을 포함하는 것으로 바인딩 모듈(116)을 예시하지만, 청구되는 주제로부터 벗어나지 않으면서, 피쳐의 임의의 조합이 포함될 수 있고/있거나 배제될 수 있다는 것이 인식되고 이해되어야 한다. 또한, 예시된 피쳐가 별개의 모듈로서 도시되지만, 하나 이상의 피쳐는 하나의 모듈, 별개의 모듈, 또는 이들의 임의의 조합으로 구현될 수 있다는 것이 인식되고 이해되어야 한다.

바인딩 모듈(116)은, 이 특정 예에서, 하나 이상의 동적 타입 시스템 지연 초기화 모듈(Dynamic Type System Deferred Initialization module; 802), 하나 이상의 동적 타입 시스템 다이렉트 함수 모듈(Dynamic Type System Direct Functions module; 804), 하나 이상의 동적 타입 시스템 객체 프록시 모듈(Dynamic Type System Object Proxy module; 806), 하나 이상의 동적 타입 시스템 오버레이 모듈(Dynamic Type System Overlay module; 808), 하나 이상의 동적 타입 시스템 재초기화 모듈(Dynamic Type System Re-initialization module; 810), 하나 이상의 액세서 특성 모듈(Accessor Property module; 812), 하나 이상의 대체 특성 모듈(Replacement Property module; 814), 및 하나 이상의 데드 코드 제거 모듈(Dead Code Elimination module; 816)을 포함하는데, 이들의 각각은 하기에서 설명된다. 이들 피쳐의 어느 정도의 하이 레벨의 개관으로서, 후속하는 논의를 고려하고, 그 다음, 각 피쳐의 고유한 부제(sub-heading) 하에서의 각각의 피쳐의 논의가 후속한다.

하나 이상의 실시형태에서, 동적 타입 시스템 지연 초기화 모듈(802)은, 요청시 및/또는 필요에 따라, 하나 이상의 동적 타입 시스템 객체가 초기화되는 것을 가능하게 하는데, 이것은 하기에서 명백하게 될 것이다.

몇몇 실시형태에서, 동적 타입 시스템 다이렉트 함수 모듈(804)은 리다이렉트 구조체, 예컨대 도 2의 트램펄린(212)으로서 구성될 수 있다. 동적 타입 시스템 다이렉트 함수 모듈(들)(804)은 하나 이상의 함수 인스턴스가 네이티브 객체로서 스크립팅 엔진 안으로 직접적으로 구축되는 것을 가능하게 한다. 대안적으로 또는 추가적으로, 동적 타입 시스템 다이렉트 함수 모듈(들)(804)은 네이티브 객체로부터 레이아웃 엔진 지지 객체(layout engine backing object)로의 호출을 생성하도록 구성될 수 있다. 지지 객체는, 요청된 기능성을 구현하고, 강화하고, 및/또는 실행할 수 있는 객체이다.

하나 이상의 실시형태에서, 동적 타입 시스템 객체 프록시 모듈(806)은 지지 객체, 예컨대 레이아웃 엔진의 객체가, 관련된 스크립팅 엔진 객체의 거동을 오버라이딩하거나 또는 변경하는 것을 가능하게 한다.

하나 이상의 실시형태에서, 동적 타입 시스템 오버레이 모듈(808)은 스크립팅 엔진에서 실행하는 스크립트가, 하기에서 추가로 설명되는 바와 같이, 대응하는 레이아웃 엔진 객체와 관련되는 API를 대체하고, 수정하고, 및/또는 제거하는 것을 가능하게 한다.

하나 이상의 실시형태에서, 동적 타입 시스템 재초기화 모듈(810)은 하나 이상의 경계 교차(cross-boundary) 객체, 예컨대, 비제한적인 예로서, 상이한 타입 시스템으로 전송되는 객체(들)의 재초기화를 가능하게 하도록 구성된다.

하나 이상의 실시형태에서, 액세서 특성 모듈(812)은, 하기에서 추가로 설명되는 바와 같이, 레이아웃 엔진 객체의 게터(getter) 및 세터(setter) 기능성이 노출되어 스크립팅 언어에 네이티브한 방식으로 관련 스크립팅 언어 객체와 통합되는 것을 가능하게 한다. 게터 함수 및 세터 함수는 변수 또는 객체가 액세스될 때 소정의 기능성을 실행하도록 구성될 수 있다.

하나 이상의 실시형태에서, 대체 특성 모듈(814)은 객체에 대한 리드 온리(read-only) 특성 할당을 강화하도록 구성될 수 있고, 그 결과 객체와 관련되는 값은 다른 관련 객체로 리다이렉트될 수 있다.

하나 이상의 실시형태에서, 데드 코드 제거 모듈(816)은 코드 실행을 더 효율적으로 만들도록 구성된다. 몇몇 실시형태에서, 데드 코드 제거 모듈(816)은 의도된 수신측을 갖지 않는 것으로 결정된 코드의 실행을 스킵하도록 구성될 수 있는데, 이것은 하기에서 설명될 것이다.

바인딩 모듈(116)에 포함되는 다양한 피쳐의 하이 레벨의 개관을 설명하였지만, 이제, 각각의 피쳐의 더 상세한 논의를 고려한다.

동적 타입 시스템 지연 초기화

몇몇 초기화 시스템은 복수의 객체, 예를 들면, 500개의 객체 및 더 많은 함수, 예를 들면 3000개의 함수를 포함할 수 있다. 몇몇 방식에서, 전체 동적 타입 시스템은 스크립팅 엔진에 미리 로딩될 수 있다. 이렇게 하는데 걸리는 시간은 기동 시간의 상당한 양을 차지할 수 있다는 것은 두말할 필요가 없다. 이 시간은, 예를 들면, 웹 페이지가 (예를 들면, 광고 등을 위한) 많은 프레임을 가지며 각각의 프레임이 동적 타입 시스템을 로딩해야만 할 때 배가될 수 있다. 하나 이상의 실시형태에서, "온 디맨드" 형식으로 동적 타입 시스템을 구축하기 위해, "지연된" 타입 시스템 초기화가 활용될 수 있다. 이렇게 하는 것은 전체 동적 타입 시스템을 미리 로딩하는 시간에서의 영향을 완화할 수 있다. 따라서, 어떠한 DOM API도 활용되지 않으면, 타입 시스템 초기화 비용이 거의 초래되지 않는다. 예를 들면, 리턴 값에 의해 각각의 새로운 타입이 필요하게 될 때, 하기에서 설명되는 방식은 그 타입과 그것의 종속 타입 및 함수를 그들이 필요되기 직전에 생성할 수 있다. 이것은 DOM 타입에 의해 사용되는 초기화 비용을 상환할 수 있고, 미사용 타입에 대한 전체 비용을 제거할 수 있다.

몇몇 실시형태에서, 타입 시스템의 하나 이상의 타입은, 케스케이드형의 필요에 따른 방식(cascaded, as-needed manner)으로 초기화될 수 있다. 예를 들면, 타입 시스템의 특정 타입은, 모든 단계가 완료된 이후 그 특정 타입이 타입 시스템에서 액세스가능하게 되고 실체화되도록(substantiated), 다수의 단계에서 초기화될 수 있다. 타입 시스템의 타입에 관한 정보는, 타입 시스템이 타입을 인식하도록, 초기에 노출되거나, 선언되거나, 또는 관련 식별자를 가질 수 있다. 그러나, 타입(들)의 완전한 초기화는, 타입(들)이 액세스되어야 할 때까지, 지체되고/되거나 지연될 수 있다. 대안적으로 또는 추가적으로, 타입이 액세스되지 못하면, 그것은 완전히 실체화되지 않으며, 따라서 메모리에서 생성되는 객체의 수를 감소시키게 된다. 예를 들면, 초기화를 지연시키는 것은 액티브하게 사용되고 있는 객체에 대해서만 메모리 사용량을 확보할 수 있다.

하나 이상의 실시형태에서, 적어도 하나의 타입과 관련되는 정보의 기본 세트는 타입 시스템에서 스크립트 및/또는 스크립팅 엔진에게 노출될 수 있다. 정보의 기본 세트는 임의의 종류의 타입, 예컨대, 비제한적인 예로서, 객체, 메소드, 특성, 프로토타입 등과 관련될 수 있다. 몇몇 실시형태에서, 정보의 기본 세트는 타입(들)과 관련되는 생성자(constructor)를 포함한다. 정보에 기초하여, 스크립트 및/또는 스크립팅 엔진은, 액세스에 이용가능한 다양한 타입을 검사할 수 있다. 몇몇 실시형태에서, 스크립트 및/또는 스크립팅 엔진은, 동적으로 타입을 질의하고(querying)/하거나 타입에 바인딩하지 않고도, 다양한 타입을 검사할 수 있다. 예를 들면, 다양한 타입은 기동시 타입 시스템에서 초기에 노출될 수 있다. 런타임 성능은, 시간 소모적인 동작일 수 있는 질의에 대한 필요성을 감소시키거나 또는 제거하는 것에 의해 향상될 수 있다. 대신, 스크립트 및/또는 스크립팅 엔진은 초기 정보를 통해 다양한 타입을 알 수 있고, 스크립트에서의 추가적인 단계 없이 그 타입을 그에 맞게 액세스할 수 있다.

정보의 기본 세트와 관련되는 타입의 액세스시, 타입의 생성자는 관련 프로토타입 정보를 가리키도록 및/또는 관련 프로토타입 정보에 링크하도록 구성될 수 있다. 몇몇 실시형태에서, 생성자는 부모, 형제, 및/또는 자식 관련성(association)을 가리키도록 구성될 수 있다. 대안적으로 또는 추가적으로, 특정 타입 또는 프로토타입을 요청하는 것은 또한, 관련 프로토타입, 예컨대 특정 타입의 부모 또는 슈퍼 프로토타입(super-prototype)이 액세스에 이용가능하게 되는 것을 가능하게 할 수 있다. 관련 타입의 링크용 프로토타입(linking prototype)은, 객체 및/또는 프로토타입의 세트 사이의 일련의 관계를 가능하게 할 수 있고, 따라서 객체(들) 사이의 중복 코드를 더 감소시키게 된다.

하나 이상의 특정 프로토타입을 가리키는 것 및/또는 링크하는 것에 응답하여, 특정 프로토타입(들)의 일정한 특성 및/또는 메소드는 초기화될 수 있다. 예를 들면, 특성 및/또는 메소드는 메모리에서 생성되어 디폴트 값을 가지고 초기화될 수 있다. 대안적으로 또는 추가적으로, 초기화된 특성 및/또는 메소드는 특정 프로토타입(들)에 어태치될 수 있다.

특성 및/또는 메소드를 초기화하는 것에 응답하여, 인스턴스 타입 동작이 생성되어 레이아웃 엔진의 관련 객체에 결부된다(tied). 예를 들면, 인스턴스 타입 동작은 스크립팅 엔진 환경에서 var 객체를 생성하도록 그리고 var 객체를 그것의 관련 레이아웃 엔진 객체에 바인딩하도록 구성될 수 있는데, 이들의 예는 상기에서 그리고 하기에서 제공된다.

한 예로서, 하나 이상의 실시형태에 따른 방법에서의 단계를 설명하는 흐름도를 예시하는 도 9를 고려한다. 방법은 임의의 적절한 하드웨어, 소프트웨어, 펌웨어, 또는 이들의 조합에 의해 수행될 수 있다. 적어도 몇몇 실시형태에서, 방법의 양태는 클라이언트 디바이스 상에서 실행하는 소프트웨어, 예컨대 적절히 구성된 바인딩 모듈에 의해 수행된다.

단계 900은 하나 이상의 타입과 관련되는 정보의 기본 세트를 타입 시스템에 노출시킨다. 예를 들면, 정보의 기본 세트는 타입(들)과 관련되는 하나 이상의 생성자를 포함할 수 있다. 몇몇 실시형태에서, 정보의 기본 세트는 기동시 타입 시스템에 정적으로(statically) 노출될 수 있다.

정보의 기본 세트에 액세스하는 것에 응답하여, 단계 902는 하나 이상의 타입과 관련되는 적어도 하나의 프로토타입 구현예에 대한 적어도 하나의 링크를 초기화한다. 예를 들면, 생성자는 관련 프로토타입 구현예를 가리키도록 구성될 수 있다. 생성자에 액세스하는 것은, 관련 프로토타입 구현예에 대한 링크로 하여금 초기화되게 할 수 있다.

단계 904는 관련 프로토타입 구현예를 초기화하고, 몇몇 실시형태에서, 초기화된 프로토타입 구현예는 초기화되고 있는 타입에 어태치될 수 있다.

단계 906은 초기화된 타입과 관련되는 인스턴스 객체를 생성하고, 그 인스턴스를 지지 객체, 예컨대 레이아웃 엔진의 객체에 추가로 바인딩한다. 몇몇 실시형태에서, 상기에서 설명되는 바와 같이, 인스턴스 객체는 스크립팅 엔진의 메모리 공간에 상주할 수 있고, 한편 지지 객체는 레이아웃 엔진에 상주한다.

상기에서 설명되는 바와 같은 동적 타입 시스템에서의 초기화를 지연시키는 것 및/또는 캐스케이드화 하는 것은, 액티브하게 활용되고 있는 객체에 대해 메모리를 확보하는 것 외에, 액세스시 타입이 효율적인 방식으로 구축되는 것을 가능하게 한다. 동적 타입 시스템 지연 초기화를 고려하였지만, 이제, 동적 타입 시스템 다이렉트 함수의 논의를 고려한다.

동적 타입 시스템 다이렉트 함수

몇몇 시스템에서, 함수는 이전에는 호스트 객체로서 취급되었고 2 단계의 프로세스에서 특정 인터페이스를 사용하여 질의되었다. 먼저, ID를 취출하기 위해 함수의 이름이 질의되었고, 그 다음, ID를 이용하여, 함수가 호출되었다. 이 두 단계의 프로세스는, 특히 이 것이 반복적으로 사용될 때, 아주 비용이 많이 들고 비효율적인 것으로 밝혀졌다.

하나 이상의 실시형태에서, 이 두 단계의 프로세스는 동적 타입 시스템의 객체에 대해 완전히 제거될 수 있다. 객체는 네이티브 스크립팅 엔진으로서 직접적으로 구축될 수 있고(예를 들면, 자바스크립트 객체) 관련 내부 룩업 프로세스를 사용하여 액세스될 수 있다. 함수 인스턴스는 스크립팅 엔진 안으로 직접적으로 구축될 수 있고 동일한 프로세스를 사용하여 룩업된다. 예를 들면, 스크립팅 엔진 룩업 프로세스를 사용하여 다이렉트 함수가 획득되면, 그것의 호출은 DOM의 트램펄린에 대한 호출을 생성한다. 트램펄린은, 정확한 타입의 객체만이 호출을 수행할 수 있다는 것을 보장하기 위해, 전달되는 파라미터 및 호출하는 객체(들)를 취하는 호출자 검증(caller validation)을 수행할 수 있다. 하나 이상의 실시형태에서, 이것은 베이스 객체로 캐스팅하는 것, 객체의 타입 ID 정보를 취출하는 것, 허용된 타입 ID의 세트에 비교하는 것에 의해 행해질 수 있다.

보다 구체적으로는, 몇몇 실시형태에서, 스크립팅 엔진과 레이아웃 엔진 사이의 호출을 중개하기(bridge) 위해, 다이렉트 함수 또는 상기에서 설명된 바와 같이 "트램펄린"으로서도 또한 알려진 브릿지 함수가 생성될 수 있다. 스크립팅 엔진에 네이티브한 객체에 액세스하기 위해 사용되는 메소드를 통해(예를 들면, 상기에서 언급된 스크립팅 엔진의 내부 룩업 프로세스를 통해) 스크립팅 엔진이 브릿지 함수를 룩업하고 액세스할 수 있도록, 스크립팅 언어 함수가 브릿지 함수를 래핑(wrap)할 수 있다. 브릿지 함수는 또한, 유입 파라미터를 관련 레이아웃 엔진 객체에 그리고 호출을 관련 레이아웃 엔진 객체의 하나 이상의 메소드에 마셜링하도록(marshal) 구성될 수 있다. 대안적으로 또는 추가적으로, 브릿지 함수는 또한, 상기에서 언급된 바와 같이, 함수의 호출자의 검증, 예컨대 호출자가 정확한 호출 타입을 갖는지의 검증을 가능하게 하도록 구성될 수 있다.

스크립팅 엔진 안으로 직접적으로 구축되는 및/또는 스크립팅 엔진을 통해 구축되는 객체는 네이티브 메소드를 사용하는 스크립팅 엔진에 의해 액세스될 수 있다. 예를 들면, 스크립팅 언어를 통해 생성되는 객체는 상기에서 언급된 바와 같은 네이티브 룩업 메소드를 사용하는 스크립팅 엔진에 의해 액세스될 수 있다. 몇몇 실시형태에서, 스크립팅 언어 함수는 브릿지 함수를 래핑할 수 있고, 따라서 스크립팅 엔진이 래핑된 함수를 통해 브릿지 함수에 액세스하는 것을 가능하게 한다. 래핑된 함수가 스크립팅 언어에 네이티브하기 때문에, 그것은 스크립팅 언어 및/또는 스크립팅 엔진에 의해 다른 네이티브 객체로서 조작될 수 있다. 예를 들면, 몇몇 실시형태에서, 래핑된 함수는 다른 객체에 어태치될 수 있고/있거나 다른 객체에 근거를 둘 수 있는데, 이것은 결국에는, 관련 기능성을 다른 객체에 어태치할 수 있다.

예로서, 하나 이상의 실시형태에 따른, 브릿지 함수와 관련되는 다양한 관계를 예시하는 도 10을 고려한다. 하얀색의 박스는 스크립팅 언어로 구현되는 기능성을 나타내고, 한편 회색의 박스는 스크립팅 언어 이외의 것으로, 예를 들면, C++로 구현되는 기능성을 나타낸다. 도 10은 하나 이상의 스크립팅 언어 래퍼 함수(1002), 하나 이상의 브릿지 함수(1004), 하나 이상의 레이아웃 엔진 객체(1006) 및 하나 이상의 마셜/디마셜 모듈(Marshal/De-Marshal module; 1008)을 포함한다. 추가적으로, 도 10은, 스크립팅 언어 래퍼 함수(1002)로의, 마셜/디마셜 모듈(1008) 안으로의, 레이아웃 엔진 객체(들)(1006)로의 하나 이상의 호출을 각각 나타내는 플로우(1010, 1012 및 1014)를 포함한다. 화살표가 설명의 간이성을 위해 일방향 화살표로 예시되지만, 함수 호출의 화살표는, 청구되는 주제의 범위를 벗어나지 않고도, 양방향일 수 있다는 것이 인식되어야 한다.

스크립팅 언어 래퍼 함수(1002)는 브릿지 함수(1004)를 래핑하는 스크립팅 언어 함수를 나타낸다. 스크립팅 언어 래퍼 함수(1002)는 스크립팅 언어에 네이티브하며, 따라서, 스크립팅 언어가, 상기에서 설명된 프로시져와 같이, 표준 프로시져를 사용하여 함수를 호출 및 조작하는 것을 허용하게 된다. 스크립팅 언어 래퍼 함수(1002)는, 래퍼 함수가 브릿지 함수(1004)를 소환하는 것을 가능하게 하는 정보를 포함한다.

다른 것들 중에서도, 브릿지 함수(1004)는 다양한 형태의 검증을 수행하도록 구성될 수 있다. 예를 들면, 몇몇 실시형태에서, 브릿지 함수(1004)는 호출자 검증을 수행하도록 구성될 수 있다. 호출자 검증은, 정확한 호출 타입을 갖는 객체만이 함수를 호출하고 있다는 것을 보장한다. 이것은 많은 방식으로, 예컨대 객체 타입 ID(identification) 정보를 활용하는 것에 의해 달성될 수 있다. 몇몇 실시형태에서, 상기에서 언급된 바와 같이, 객체는 베이스 객체로 캐스팅될 수 있고, 그것의 관련 ID 정보는 허용된 타입 ID의 세트에 대해 비교될 수 있다. 허용된 타입 ID의 세트는, 하나 이상의 계층적 관계에 포함되는 허용된 타입을 반영하도록 또한 구성될 수 있다. 대안적으로 또는 추가적으로, 브릿지 함수(1004)는 함수로 전달되고 있는 하나 이상의 파라미터를 검증하도록 구성될 수 있다.

브릿지 함수(들)(1004)는 호출을 하나 이상의 관련 레이아웃 엔진 객체로 지향시키도록 또한 구성될 수 있다. 몇몇 실시형태에서, 브릿지 함수(1004)는, 검증이 수행된 및/또는 통과된 이후 호출을 관련 레이아웃 객체로 지향시킬 수도 있는데, 이들의 예는 상기에서 제공되어 있다. 또한, 관련 레이아웃 객체에 대한 호출은 임의의 적절한 메소드를 통해, 예컨대 레이아웃 객체의 하나 이상의 API를 통해 지시될 수 있다. 파라미터는 마셜/디마셜 모듈(1008)의 사용을 통해 브릿지 함수(1004)에 의해 전달될 수 있다. 마셜/디마셜 모듈(1008)은, 객체 및/또는 데이터가 하나의 프로그램으로부터 다른 것으로, 예컨대 스크립팅 엔진으로부터 레이아웃 엔진으로 전송되는 것을 가능하게 하는 기능성을 나타낸다.

레이아웃 엔진 객체(1006)는, 레이아웃 엔진과 관련되는 임의의 종류의 객체, 함수 등을 나타낸다. 예를 들면, 레이아웃 엔진 객체(1006)는 레이아웃 엔진에 의해 렌더링되는 다큐먼트, 다큐먼트 내의 엘리먼트 등일 수 있을 것이다. 레이아웃 엔진 객체(1006)는, 외부에 노출된 메소드, 함수, 및 레이아웃 엔진 객체(1006) 외부의 객체가 레이아웃 엔진 객체에게 기능성을 요청하는 것뿐만 아니라 데이터를 교환하는 것을 가능하게 하는 다른 형태의 액세스를 포함한다. 몇몇 실시형태에서, 데이터는 마셜/디마셜 모듈(1008)의 사용을 통해 교환될 수 있다.

플로우(1010, 1012, 및 1014)는, 다양한 함수 및/또는 모듈이 상호작용할 수 있는 방식의 일 예를 나타낸다. 플로우(1010)는 스크립팅 엔진으로부터 스크립팅 언어 래퍼 함수(1002)로의 호출을 나타낸다. 상기에서 논의된 바와 같이, 스크립팅 엔진은 스크립팅 엔진에 네이티브한 임의의 방식으로 스크립팅 언어 래퍼 함수(1002)를 호출할 수 있다. 호출을 받으면, 플로우(1010)에 의해 나타내어진 바와 같이, 스크립팅 언어 엔진 래퍼 함수(1002)는 브릿지 함수(1004)를 소환한다. 파라미터가 전달되어야 한다는 것을 결정하면, 몇몇 실시형태에서, 브릿지 함수(1002)는, 플로우(1012)에 의해 예시된 바와 같이, 마셜/디마셜 모듈(1008)을 활용하거나 호출할 수 있다. 마셜/디마셜 모듈(1008)은, 응답으로, 플로우(1014)에 의해 예시된 바와 같이, 파라미터를 레이아웃 엔진 객체(1006) 안으로 전달할 수 있다. 대안적으로 또는 추가적으로, 브릿지 함수(1004)는 API를 통해 레이아웃 엔진(1006) 안에 직접 액세스할 수 있는데, 이것은 도 10에서는 예시되어 있지 않다.

브릿지 함수는 스크립팅 언어 래퍼 함수와 조합하여 레이아웃 엔진과 스크립팅 엔진 사이의 효율적인 액세스를 용이하게 한다. 추가적으로, 조합은 또한, 객체가 스크립팅 엔진에 네이티브한 방식으로 요청되지만, 상기에서 논의되는 바와 같이, 레이아웃 엔진을 통해 검증되는 것을 가능하게 한다. 동적 타입 시스템 다이렉트 함수를 설명하였지만, 이제, 동적 타입 시스템 객체 프록시의 논의를 고려한다.

동적 타입 시스템 객체 프록시

몇몇 DOM 객체는, 네이티브 스크립팅 엔진 객체가 이용가능한 것을 넘어서는 특수한 능력을 갖는다. 예를 들면, 페이지 엘리먼트가 추가되고/되거나 제거될 때 자신의 컨텐츠가 변하고 업데이트하는 "동적 어레이"의 타입을 DOM이 지원하면, 동적 타입 시스템을 통해 DOM 객체를 스크립팅 엔진 안으로 이동시키는 것에 의해, 이들 여분의 능력은 스크립팅 엔진에 의해 네이티브하게 제공되지는 않는다. 스크립팅 엔진 객체, 예를 들면, 자바스크립트 객체를 통한 이들 피쳐를 용이하게 하기 위해, "타입 동작"으로 알려진 프록시 래퍼가 모든 객체에게 제공된다.

따라서, 다양한 엘리먼트는 레이아웃 엔진 객체가 관련 스크립팅 엔진 객체의 능력을 오버라이딩하는 것을 가능하게 한다. 하나 이상의 실시형태에서, 프록시 래퍼는, 제너릭 또는 네이티브 스크립팅 언어 동작이 스크립팅 엔진 객체와 관련되고/되거나 스크립팅 엔진 객체에 적용될 수 있도록, 스크립팅 엔진 객체에 제공될 수 있다. 몇몇 실시형태에서, 프록시 래퍼는 추가적인 및/또는 대안적인 거동을 포함하도록 레이아웃 엔진 객체에 의해 수정될 수 있다.

상기에서 논의된 바와 같이, 이중성 객체는 스크립팅 언어 객체 및 레이아웃 엔진 객체를 포함할 수 있다. 스크립팅 언어 객체는 스크립팅 언어에 네이티브한 임의의 타입의 객체, 예컨대 스크립팅 언어 메모리 공간에서 생성될 수 있는 객체, 함수, 및/또는 프로토타입으로서 구체화될 수 있다. 마찬가지로, 레이아웃 엔진 객체는 레이아웃 엔진 메모리 공간에서 레이아웃 엔진에서 및/또는 레이아웃 엔진에 의해 생성되는 임의의 타입의 객체로서 구체화될 수 있는데, 이들의 예는 상기에서 제공되어 있다. 몇몇 실시형태에서, 레이아웃 엔진 객체는 스크립팅 언어 객체와 관련되는 특성, 함수, 및/또는 거동을 변경할 수 있다. 예를 들면, 스크립팅 언어 객체와 관련되는 타입 동작은 스크립팅 언어의 네이티브 거동을 실행할 수 있다. 몇몇 경우에서, 스크립팅 언어의 네이티브 거동은, 관련 레이아웃 엔진에 네이티브한 거동과는 상이하거나 동기에서 벗어날 수도 있다. 예를 들면, 상기 언급된 바와 같이, 레이아웃 엔진에 의해 지지되는 몇몇 피쳐 또는 여분의 능력은, 스크립팅 언어에서 필적할만한 네이티브 지원을 갖지 않을 수도 있다. 레이아웃 엔진 객체는, 호출시 추가적인 및/또는 완전히 상이한 거동을 포함하도록 스크립팅 언어 객체의 타입 동작을 변경할 수 있다. 상기 언급된 바와 같은 동적 어레이를 지원하는 능력과 같은 임의의 적절한 타입의 변경이 포함될 수 있는데, 이 경우, 어레이의 컨텐츠는 업데이트되고, 추가되고, 및/또는 제거될 수 있다. 추가 예는, 특성, 특성 검출뿐만 아니라, 예를 들면, 자바스크립트 룩업 동작 프로세스 동안 타입 동작이 사용되어야만 하는 때에 걸친 또는 타입 동작이 자바스크립트 룩업 동작 프로세스를 통해 특성의 위치를 찾는 데 실패한 이후의 제어를 획득하고 설정하기 위한 오버라이드를 제공하는 타입 동작을 사용하는 것을 포함한다. 이들 변경을 통해, 레이아웃 엔진 객체는 자기 고유의 네이티브 거동을 흉내내도록 스크립팅 언어 객체를 변경하거나 또는 스크립팅 언어 객체에 대해 거동을 추가할 수 있다.

하나 이상의 실시형태에 따른 방법에서의 단계를 설명하는 흐름도를 예시하는 도 11을 고려한다. 방법은 임의의 적절한 하드웨어, 소프트웨어, 펌웨어, 또는 이들의 조합에 의해 수행될 수 있다. 적어도 몇몇 실시형태에서, 방법의 양태는, 도 1의 바인딩 모듈(116), 레이아웃 엔진(112), 및/또는 스크립팅 엔진(118)과 같은 컴퓨팅 디바이스 상에서 실행하는 적절히 구성된 소프트웨어에 의해 수행된다.

단계 1100은 레이아웃 엔진 객체를 생성한다. 레이아웃 엔진 객체의 생성은 임의의 적절한 방식으로 수행될 수 있다. 임의의 적절한 타입의 레이아웃 엔진 객체가 생성될 수 있는데, 이들의 예는 상기에서 제공되어 있다. 단계 1102는 스크립팅 언어 객체, 예컨대 스크립팅 엔진 메모리 공간에 네이티브한 객체를 생성한다. 단계 1104는, 레이아웃 엔진 객체에 네이티브한 거동을 모델링하기 위해 스크립팅 언어 객체와 관련되는 타입 동작을 수정하는데, 이들의 예는 상기에서 그리고 하기에서 제공된다.

동적 타입 시스템 객체 프록시를 설명하였지만, 이제 동적 타입 시스템 오버레이의 논의를 고려한다.

동적 타입 시스템 오버레이

동적 타입 시스템의 API는 가변적인 것에 비해 레거시 타입 시스템은 정적이었으며 아주 제한된 방식으로만 변경될 수 있었다. 따라서, 자바스크립트 프로그램은 "내장형" DOM API를 그들 고유의 것과 대체할 수 있거나, API를 캐싱하고 호출할 수 있거나, 심지어 API를 완전히 삭제할 수 있다. 이들 경우에서, 이것은 API 뒤에서 코드를 지원하는 정적 DOM이 아니라 다이렉트 함수 엔트리 포인트에만 영향을 끼친다.

하나 이상의 실시형태에서, 가변성(또는 그 결여)은 개개의 특성의 특성 디스크립터(descriptor)를 통해 제어된다. 특성 디스크립터는 스크립팅 엔진, 예를 들면, 자바스크립트 엔진에 의해 소비가능한 메타 정보를 구비한다. 특성 디스크립터는 제어 열거가능성(enumerability), 구성가능성(예를 들면, API가 변경될 수 있는지 또는 제거될 수 있는지의 여부), 기록가능성(예를 들면, 데이터 특성 또는 필드가 그들의 값을 변경되게 할 수 있는지의 여부)를 제공한다.

하나 이상의 실시형태에서, API가 스크립팅 엔진, 예를 들면, 자바스크립트 엔진으로 초기화되면, 내장형 스크립팅 엔진 API는, 이들이 네이티브 객체인 것처럼 관련 객체에 대해 작동한다. 예를 들면, "instanceof"로 알려진 연산자는, 주어진 인스턴스가 주어진 타입의 멤버인지의 여부를 체크한다. 자바스크립트 구현예는 인스턴스의 타입을 질의하고, 관련 특성의 타입 체인을 횡단하여 연산자에 대한 우측 인수(right-argument)를 각각의 DOM 타입의 프로토타입 객체에 비교할 수 있다. 하나 이상의 실시형태에서, 특성 디스크립터는, 임의의 다른 자바스크립트 객체와 동일한 자바스크립트 네이티브 API를 통해 액세스되고 수정된다. 이 방식에서, 자바스크립트 프로그램은, 정적 DOM 코드에 영향을 끼치지 않으면서 DOM API를 동적으로 수정할 수 있다. 이 통합은 오버헤드에서의 복잡성이 적은 더 큰 통합 및 원활한 거동을 허용한다.

하나 이상의 실시형태에 따른 방법에서의 단계를 설명하는 흐름도를 예시하는 도 12를 고려한다. 방법은 임의의 적절한 하드웨어, 소프트웨어, 펌웨어, 또는 이들의 조합에 의해 수행될 수 있다. 적어도 몇몇 실시형태에서, 방법의 양태는, 도 1의 바인딩 모듈(116), 레이아웃 엔진(112), 및/또는 스크립팅 엔진(118)과 같은 컴퓨팅 디바이스 상에서 실행하는 적절히 구성된 소프트웨어에 의해 수행된다.

단계 1200은 레이아웃 엔진 객체를 생성한다. 레이아웃 엔진 객체의 생성은 임의의 적절한 방식으로 수행될 수 있다. 임의의 적절한 타입의 레이아웃 엔진 객체가 생성될 수 있는데, 이들의 예는 상기에서 제공되어 있다. 단계 1202는 스크립팅 언어 객체, 예컨대 스크립팅 엔진 메모리 공간에 네이티브한 객체를 생성한다. 단계 1204는, 스크립팅 언어 객체를 통해 레이아웃 엔진 객체와 관련되는 적어도 하나의 API를 동적으로 수정하는데, 이들의 예는 상기에서 그리고 하기에서 제공된다.

동적 타입 시스템 오버레이를 설명하였지만, 이제, 동적 타입 시스템 재초기화의 논의를 고려한다.

동적 타입 시스템 재초기화

다양한 실시형태는 스크립팅 엔진 환경에 네이티브한 객체가 제2 스크립팅 엔진 및/또는 타입 시스템에 전송되는 것을 가능하게 한다. 이러한 것은, 예를 들면, 객체의 타입이 정보의 부주의한 누설을 제공할 수 있는 보안 시나리오를 완화할 수 있다. 적어도 몇몇 실시형태에서, 객체의 적어도 하나의 특성 및/또는 프로토타입과 관련되는 정보는 제2 스크립팅 엔진 및/또는 타입 시스템으로 전송될 수 있다. 몇몇 실시형태에서, 초기 상태에서 변경된 객체는 그 상태 변경을 그대로 하여 전송될 수 있다.

동작에서, 스크립팅 언어 환경에 네이티브한 객체가 생성될 수 있다. 이러한 것은, 예를 들면, 레이아웃 엔진이 네이티브 스크립팅 언어 객체를 스크립팅 엔진으로 리턴하는 것 등을 통해, 스크립트를 실행하는 스크립트 엔진에 의해 발생할 수 있다. 때때로, 레이아웃 엔진은, 제1 스크립팅 엔진에 네이티브한 객체가 다른 스크립팅 엔진으로 전송되거나 재초기화되게 하는 것을 소망할 수도 있다. 예를 들면, 몇몇 경우에서, 레이아웃 엔진은, 상기에서 설명된 바와 같이, 이중성을 갖는 스크립팅 언어 객체가 제2 스크립팅 엔진으로 전송되는 것을 소망할 수도 있다. 이렇게 하기 위해, 제1 스크립팅 엔진 객체의 속성은 제2 스크립팅 엔진 객체로 복제되고/되거나 변환될 수 있고, 따라서 제1 스크립팅 엔진 객체를 제2 스크립팅 엔진으로 효율적으로 전송하거나 재초기화하게 된다. 이런 방식에서, 이중성 객체 사이의 바인딩은 다수의 스크립팅 엔진 사이에서 전송될 때 보존될 수 있다. 추가적으로, 몇몇 실시형태에서, 제1 스크립팅 언어 객체는 제2 스크립팅 언어 객체에 영향을 끼치지 않으면서 제거될 수 있다.

추가적으로, 스크립팅 언어는 객체의 특성, 예컨대 프로토타입, 함수, 상속(inheritance) 및/또는 특성 체인 등이 동적으로 변경되는 것을 가능하게 할 수 있다. 예를 들면, 디폴트 값, 디폴트 특성, 디폴트 상속 체인 등은 시간에 걸쳐 동적으로 변경될 수 있다. 몇몇 실시형태에서, 제1 스크립팅 엔진의 객체의 변경된 특성은, 예컨대 이들을 복제하는 것에 의해, 제2 스크립팅 엔진의 대응하는 객체로 전송될 수 있다. 이 방식에서, 스크립팅 객체와 관련되는 정적인 그리고 동적인 변경은 여러 경계에 걸쳐 보존될 수 있다.

하나 이상의 실시형태에 따른 방법에서의 단계를 설명하는 흐름도를 예시하는 도 13을 고려한다. 방법은 임의의 적절한 하드웨어, 소프트웨어, 펌웨어, 또는 이들의 조합에 의해 수행될 수 있다. 적어도 몇몇 실시형태에서, 방법의 양태는, 도 1의 바인딩 모듈(116), 레이아웃 엔진(112), 및/또는 스크립팅 엔진(118)과 같은 컴퓨팅 디바이스 상에서 실행하는 적절히 구성된 소프트웨어에 의해 수행된다.

단계 1300은, 제1 스크립팅 엔진의 언어에 네이티브한 제1 스크립팅 언어 객체를 생성한다. 제1 스크립팅 언어 객체의 생성은 임의의 적절한 방식으로 수행될 수 있다. 대안적으로 또는 추가적으로, 임의의 적절한 타입의 스크립팅 언어 객체가 생성될 수 있는데, 이들의 예는 상기에서 제공되어 있다. 단계 1302는, 제2 스크립팅 언어 객체의 언어에 네이티브한 제2 스크립팅 언어 객체를 생성한다. 몇몇 실시형태에서, 제1 및 제2 스크립팅 언어는 동일한 언어가 아니다. 다른 실시형태에서, 제1 및 제2 스크립팅 언어는 동일한 언어이다. 단계 1304는, 적어도 부분적으로, 제1 스크립팅 언어 객체와 관련되는 속성을 제1 스크립팅 엔진으로부터 제2 스크립팅 언어 객체로 복제한다. 포인터, 값, 데이터 구조 등과 같은 임의의 적절한 속성이 복제될 수 있다. 몇몇 실시형태에서, 제1 스크립팅 언어 객체에 포함되는 바인딩은 제2 스크립팅 언어 객체에 복제될 수 있다. 대안적으로 또는 추가적으로, 제2 스크립팅 언어에 따르도록 속성에 대해 변환 및/또는 전환이 적용될 수 있다.

따라서, 스크립팅 언어 객체는, 상속, 프로토타입 등과 같은 객체의 특성을 보존하면서, 다수의 스크립팅 엔진 및/또는 타입 시스템의 경계를 넘어 전송될 수 있다. 동적 타입 시스템 재초기화를 설명하였지만, 이제 액세서 특성의 논의를 고려한다.

액세서 특성

다양한 실시형태는 이중성 객체의 게터 액세서 및 세터 액세서에 대한 직접 액세스를 가능하게 한다. 게터 액세서는 각각에 대한 고유의 시그니쳐(signature)를 사용하여 세터 액세서와는 별개로 칭해질 수 있다.

액세서는, 관련 객체의 직접 노출 없이, 특성, 값, 및/또는 값에 대한 액세스를 가능하게 한다. 예를 들면, 스크립트는, 값 및/또는 특성을 저장하는 관련 객체 또는 변수에 스크립트가 직접 액세스할 필요 없이, 세터 액세서를 호출하는 것에 의해 객체의 값 또는 특성을 설정할 수 있다. 마찬가지로, 스크립트는 게터 액세스를 호출하는 것에 의해 값 또는 특성을 얻을 수 있다. 몇몇 실시형태에서, 레이아웃 엔진 객체의 게터 및 세터 기능성은 노출되어 스크립팅 언어에 네이티브한 방식으로 관련 스크립팅 언어 객체와 통합될 수 있다. 예를 들면, 레이아웃 엔진 객체와 관련되는 액세서를 스크립팅 엔진에 통합하기 위해, 다이렉트 함수가 사용될 수 있다.

몇몇 실시형태에서, 각각의 액세서는 고유의 시그니쳐를 가질 수 있다. 예를 들면, 게터 및 세터 각각에 대해, 상이한 다이렉트 함수가 사용될 수 있다. 이것은 스크립트, 객체, 프로토타입 등이 각각의 게터 및 세터를 고유하게 호출하는 것을 가능하게 한다. 따라서, 다이렉트 함수는 스크립팅 엔진으로부터 레이아웃 엔진 객체와 관련되는 액세서로의 액세스를 가능하게 하기 위해 사용될 수 있다. 각각의 세터 및 게터에 대한 고유의 다이렉트 함수의 사용을 통해, 세터 함수와 게터 함수 사이를 구별하기 위해 하나 이상의 파라미터를 공유 함수 또는 ID로 전달하는 대신, 세터 함수 및 게터 함수가 직접적으로 호출될 수 있다.

하나 이상의 실시형태에 따른 방법에서의 단계를 설명하는 흐름도를 예시하는 도 14를 고려한다. 방법은 임의의 적절한 하드웨어, 소프트웨어, 펌웨어, 또는 이들의 조합에 의해 수행될 수 있다. 적어도 몇몇 실시형태에서, 방법의 양태는, 도 1의 바인딩 모듈(116), 레이아웃 엔진(112), 및/또는 스크립팅 엔진(118)과 같은 컴퓨팅 디바이스 상에서 실행하는 적절히 구성된 소프트웨어에 의해 수행된다.

단계 1400은 레이아웃 엔진 객체를 생성한다. 레이아웃 엔진 객체의 생성은 임의의 적절한 방식으로 수행될 수 있다. 임의의 적절한 타입의 레이아웃 엔진 객체가 생성될 수 있는데, 이들의 예는 상기에서 제공되어 있다. 단계 1402는 스크립팅 언어 객체, 예컨대 스크립팅 엔진 메모리 공간에 네이티브한 객체를 생성한다. 단계 1404는, 하나 이상의 액세서를 구별하도록 구성되는 하나 이상의 파라미터 없이, 스크립팅 엔진 객체를 통해, 레이아웃 엔진 객체와 관련되는 하나 이상의 액세서를 호출한다. 예를 들면, 각각의 액세서는, 상기에서 설명된 바와 같이, 고유의 시그니쳐를 갖도록 구성될 수 있다.

액세서 특성을 설명하였지만, 이제 대체 특성을 고려한다.

대체 특성

다양한 실시형태는 리드 온리 특성이 대체 가능하게 되는 것을 가능하게 한다. 대체가능성은, 리드 온리 특성이 변경되는 상황에 관계가 있다. 구체적으로는, 리드 온리 특성이 어떤 값을 할당받으면, 원래의 리드 온리 특성은 제거되고 새롭게 할당된 특성이 그 자리를 차지한다. 하나 이상의 실시형태에서, 이 의미는 입력 액세서 값(put accessor value)을 리드 온리 특성으로 할당하는 것에 의해 지원된다. 그 다음 그것이 호출되면, 그 때 리드 온리 API를 "가리는(shadow)" 호출하는 인스턴스 객체에 대한 새로운 특성을 생성하기 위해, 관련 인터페이스가 사용된다. 이 기술을 사용하여, 리드 온리 특성에 대한 미래의 요청은 가려진 특성을 대신 정확하게 획득할 것이다. 또한, 가려진 특성이 영원히 삭제되면, 원래의 대체가능한 리드 온리는 다시 한 번 액세스가능이 된다.

따라서, 몇몇 실시형태에서, 대체가능한 값은, 리드 온리 특성을 가상적으로 대체하도록 구성되는 그림자 값(shadow value)일 수 있다. 대안적으로 또는 추가적으로, 리드 온리 특성과 관련되는 세터 액세서는 리드 온리 거동을 흉내내도록 구현될 수 있다.

몇몇 실시형태에서, 레이아웃 엔진 객체의 리드 온리 특성은 방금 설명된 방식으로 대체가능하게 되도록 구성될 수 있다. 예를 들면, 상기에서 설명된 것들과 같은 이중성 객체에서, 스크립팅 언어 객체는, 레이아웃 엔진 객체 값을 물리적으로 대체하지 않고, 스크립팅 엔진 측에 대해 대체가능한 리드 온리 특성 값을 가상으로 설정하도록 구성될 수 있다. 그 다음, 스크립팅 언어 객체와 관련되는 인스턴스 객체에 대해 그림자 값이 필드로서 저장될 수 있다. 스크립트 또는 객체가 리드 온리 특성을 질의하면, 그 때 그림자 값이 리턴될 수 있다. 하나 이상의 실시형태에서, 그림자 값을 삭제하는 것은, 상기에서 언급된 바와 같이, 리드 온리 특성, 예컨대 레이아웃 엔진 객체의 리드 온리 특성을 원래의 값으로 복원할 수 있다.

예를 들면, 리드 온리의 대체가능 특성을 설명하는 프로세스 다이어그램을 예시하는 도 15를 고려한다. 리드 온리의 대체가능 특성에 대한 액세스를 시도하는 경우, 스크립팅 언어 룩업 경로는 인스턴스 객체(1500)에서 시작한다. 인스턴스 객체(1500)로부터, 룩업 경로는 관련 프로토타입 객체(1502)로 이동한다. 몇몇 실시형태에서, 프로토타입 객체(1502)는, 액세서 특성일 수 있는 리드 온리(의 대체가능) 특성(1504)을 포함할 수 있다. 각각의 액세서(예를 들면, 게터 및 세터)는 관련 레이아웃 엔진 객체 안으로의 다이렉트 함수로서 구성될 수 있다. 또한, 세터 다이렉트 함수(1506)는, 어떤 값을 가지고 호출될 때 인스턴스 객체(1500)에 관련되는 및/또는 어태치되는 (새로운) 필드 특성(1508)을 생성하도록 구성될 수 있다. 스크립팅 엔진 룩업 경로를 통한 미래의 호출에서, 인스턴스 객체(1500)가 먼저 그 경로에 존재하기 때문에, 필드 특성(1508)이 먼저 발견되고 그 값이 리턴될 것이다.

추가 예로서, 하나 이상의 실시형태에 따른 방법에서의 단계를 설명하는 흐름도를 예시하는 도 16을 고려한다. 방법은 임의의 적절한 하드웨어, 소프트웨어, 펌웨어, 또는 이들의 조합에 의해 수행될 수 있다. 적어도 몇몇 실시형태에서, 방법의 양태는, 도 1의 바인딩 모듈(116), 레이아웃 엔진(112), 및/또는 스크립팅 엔진(118)과 같은 컴퓨팅 디바이스 상에서 실행하는 적절히 구성된 소프트웨어에 의해 수행된다.

단계 1600은 레이아웃 엔진 객체를 생성한다. 레이아웃 엔진 객체의 생성은 임의의 적절한 방식으로 수행될 수 있다. 임의의 적절한 타입의 레이아웃 엔진 객체가 생성될 수 있는데, 이들의 예는 상기에서 제공되어 있다. 단계 1602는 스크립팅 언어 객체, 예컨대 스크립팅 엔진 메모리 공간에 네이티브한 객체를 생성한다. 단계 1604는, 예컨대 상기에서 설명되는 바와 같은 그림자 값을 통해, 레이아웃 엔진 객체 특성을 물리적으로 대체하지 않고, 스크립팅 언어 객체를 통해, 레이아웃 엔진 객체의 대체가능 리드 온리 특성을 가상으로 설정한다.

대체 특성을 설명하였지만, 이제, 데드 코드 제거의 논의를 고려한다.

데드 코드 제거

다양한 실시형태는 코드 사용량의 그리고 효율성에 대한 평가가 소위 데드 코드 제거를 통해 향상되는 것을 가능하게 한다. 몇몇 실시형태에서, 코드의 실행은 이 평가에 기초하여 방지될 수 있다.

하나 이상의 실시형태에서, 코드는 그것의 관련 출력이 사용되는지의 여부를 결정하도록 평가될 수 있다. 예를 들면, 몇몇 실시형태에서, 함수 및/또는 프로토타입은, 값, 스트링, 객체 등과 같은 데이터를 의도된 수신측으로 리턴할 수 있다. 리턴된 데이터의 사용량이 평가될 수 있고, 리턴된 데이터가 사용되지 않는 것으로 결정되면, 관련 코드의 실행은 방지될 수 있다. 예를 들면, 리턴된 데이터에 대해 이러한 의도된 수신측이 존재하지 않으면, 보통 때는 리턴된 데이터를 변환하는 코드가 스킵될 수 있고 따라서 프로세싱 시간을 절약하고 성능을 향상시키게 된다. 리턴된 데이터가 의도된 수신측을 가지면, 관련 코드는 실행하도록 허용된다.

데드 코드 제거를 논의하였지만, 이제, 하나 이상의 실시형태에 따른 보안 모델의 논의를 고려한다.

보안 모델

다양한 실시형태는 별개의 도메인에서 상주하는 스크립팅 엔진 사이의 보안 상호작용을 가능하게 한다. 몇몇 경우에서, 객체 액세스를 방지하기 위해 및/또는 타입 시스템 정보에 대한 액세스를 제한하기 위해 보호수단이 활용될 수 있다. 대안적으로 또는 추가적으로, 몇몇 실시형태에서, 도메인 교차 액세스 기능성을 포함하는 함수는 안전한 것으로 마킹될 수 있고, 따라서 도메인 교차 액세스를 허용하게 된다. 몇몇 실시형태에서, 서브 윈도우 프록시는 다수의 도메인에 걸친 보안 트랜잭션을 한 윈도우와 관련되는 하나 이상의 서브 객체로 제공할 수 있다.

예로서, 예를 들면, 도 1의 보안 모듈(118)과 같은 보안 모듈에 포함되는 피쳐의 확대도를 예시하는 도 17을 고려한다. 몇몇 실시형태에서, 하기에서 설명되는 피쳐는 레이아웃 엔진 및/또는 스크립팅 엔진 내에서의 보안, 예컨대 도메인 교차 보안을 향상시키도록 디자인되는 아키텍쳐의 일부일 수 있다. 도 17이 피쳐 및/또는 모듈의 조합을 포함하는 보안 모듈(118)을 예시하지만, 청구되는 주제로부터 벗어나지 않으면서, 피쳐의 임의의 조합이 포함될 수 있고/있거나 배제될 수 있다는 것이 인식되고 이해되어야 한다. 또한, 예시된 피쳐가 별개의 모듈로서 도시되지만, 하나 이상의 피쳐는 하나의 모듈, 별개의 모듈, 또는 이들의 임의의 조합으로 구현될 수 있다는 것이 인식되고 이해되어야 한다.

예시되고 설명된 실시형태에서, 보안 모듈(118)은, 하나 이상의 정적 특성 디스크립터 모듈(1702), 하나 이상의 API 제한 모듈(1704), 하나 이상의 안전 API ID 모듈(1706), 하나 이상의 반사 함수 모듈(reflect function module; 1708), 하나 이상의 서브 윈도우 프록시 모듈(1710), 및 하나 이상의 동일 출처 최적화 모듈(same-origin optimization module; 1712)을 포함한다.

하나 이상의 실시형태에서, 정적 특성 디스크립터 모듈(1702)은 특성 디스크립터에 대한 액세스의 구성을 가능하게 하는데, 이것은 하기에서 추가로 논의될 것이다.

하나 이상의 실시형태에서, API 제한 모듈(1704)은 스크립팅 언어의 내부 라이브러리 API에 대한 액세스를 차단하는 능력을 가능하게 한다. 몇몇 실시형태에서, API에 대한 액세스는 호출자의 현재 상태, 예컨대 호출자가 동일한 도메인에 있는지 또는 상이한 도메인에 있는지의 여부에 기초하여 차단될 수 있다.

하나 이상의 실시형태에서, 안전 API ID 모듈(1706)은, 하나 이상의 API를 호출에 대해 안전한 것으로 마킹하는 능력을 가능하게 한다. 마킹된 API 중 적어도 일부는 도메인 교차 액세스를 가능하게 하도록 구성되는 API일 수 있다.

하나 이상의 실시형태에서, 반사 함수 모듈(1708)은, 관련 타입 시스템 정보를 노출시키지 않으면서, 함수 객체가 도메인에 걸쳐 교환되는 것을 가능하게 한다. 교환된 함수 객체는 호출자와 관련되는 타입 시스템에서 생성되도록 구성될 수 있는데, 이것은 하기에서 명확해질 것이다.

하나 이상의 실시형태에서, 서브 윈도우 프록시 모듈(1710)은, 주 윈도우(primary window)의 보안 특성을 상속하는 서브 윈도우를 갖는 능력을 가능하게 한다. 서브 윈도우의 보안 결정은 주 윈도우로 프록시되고/되거나 미루어진다.

하나 이상의 실시형태에서, 동일 출처 최적화 모듈(1712)은 동일 출처 보안 체크가 바이패스되는 것을 가능하게 하는데, 이것은 하기에서 추가로 설명될 것이다.

보안 모듈(118)에 포함되는 다양한 피쳐의 개관을 설명하였지만, 이제, 각각의 피쳐의 그 고유의 각각의 부제 하에서 각각의 피쳐의 보다 상세한 논의를 고려한다.

정적 특성 디스크립터 모듈(들)

다양한 실시형태는 특성 디스크립터에 대한 액세스를 구성하는 능력을 가능하게 한다. 예를 들면, 특성 디스크립터와 관련되는 개개의 속성은 특성 디스크립터에 대한 소정 형태의 액세스를 허용하도록 및/또는 허용하지 않도록 구성될 수 있다. 예를 들면, 특성 디스크립터는 가시적이도록, 비가시적이도록, 기록가능하도록, 가변적이도록, 비가변적이도록, 구성가능하도록 등이도록 구성될 수 있다. 동적 타입 시스템에서, 특성 디스크립터가 비가변적으로 마킹되면, 그것은 동적으로 변경될 수 없어서, 특성 디스크립터를 효과적으로 정적으로 만들게 된다. 특성 디스크립터의 액세스가능성 및/또는 구성가능성을 변경하는 것은, 특성 디스크립터에 대한 액세스 및/또는 변경을 제한할 수 있다.

하나 이상의 실시형태에서, 특성 디스크립터의 정의 단계 동안, 특성 디스크립터와 관련되는 다양한 속성을 설명하기 위해 정의에 태그가 포함될 수 있다. 예를 들면, 특성 디스크립터의 하나 이상의 속성을 정의하기 위해, 메타 데이터가 포함되고/되거나 특성 디스크립터 정의와 관련될 수 있는데, 이것은 하기에서 추가로 설명될 것이다. 그 다음, 특정된 속성을 인식하고, 지원하고, 및/또는 강화하도록 스크립팅 엔진이 구성될 수 있다.

상기에서 설명된 바와 같은 구성가능한 속성을 활용하는 것은, 스크립트가 특성 디스크립터를 변경하는 것을 방지할 수 있고, 따라서 더 보안적인 환경을 보장하게 된다. 특성 디스크립터를 설명하였지만, API 제한 모듈의 논의를 고려한다.

API 제한 모듈

하나 이상의 실시형태에서, 스크립팅 언어의 라이브러리 함수에 대한 액세스는 보안 정책을 고수하도록 변경되거나 제한될 수 있다. 예를 들면, 스크립팅 언어에 대한 액세스는 API가 도메인 교차 상황(cross-domain condition)에서 작용하는 것을 방지하기 위해 조건부적으로 차단되고/되거나 제한될 수 있다. API는, 비제한적인 예로서, defineProperty(), getOwnPropertyDescriptor(), HasAccessor(), getPrototypeOf() 등과 같은 임의의 형태의 라이브러리 함수일 수 있다. API의 타입 동작은 보안 정책을 강화하도록 수정되고/되거나 대체될 수 있다. 예를 들면, API가 호출되면, 수정된 타입 동작은, 보안 정책에 기초하여 액세스가 허여되어야 하는지 또는 허여되지 않아야 하는지의 여부를 결정할 수 있다. 몇몇 실시형태에서, 허여되지 않아야 한다고 결정되면, 액세스는 불능으로 될 수 있고/있거나 예외가 발생될 수 있다.

보안 정책은 임의의 형태의 정책, 예컨대 라이브러리 함수의 호출자가 동일한 도메인에 있는지 또는 동일하지 않은 도메인에 있는지의 여부와 관련되는 정책을 포함할 수 있다. 몇몇 실시형태에서, 라이브러리 함수가 별개의 도메인에 걸쳐 호출되면, 그 함수에 대한 액세스는 차단될 수 있다.

스크립팅 언어의 라이브러리 함수에 대한 액세스를 제한하는 것은 객체 및/또는 타입 시스템에 대한 원치 않는 도메인 교차 액세스를 방지할 수 있다. API 제한 모듈을 설명하였지만, 이제, 안전 API ID 모듈의 논의를 고려한다.

안전 API ID 모듈(들)

다양한 실시형태는 함수가 소위 안전 함수로서 구성되는 것을 가능하게 한다. 라이브러리에 포함되는 및/또는 객체와 관련되는 API는 "안전"으로 마킹될 수 있고, 한편 다른 관련 함수 및/또는 특성은 허용되지 않는다. 적어도 몇몇 실시형태에서, 함수를 통해 어떤 타입의 정보가 액세스될 수 있는지에 무관하게, 함수는 허용가능으로 선택적으로 마킹될 수 있다. 예를 들면, 도메인 교차 액세스를 가능하게 하는 함수는 안전한 것으로 마킹될 수 있다. 안전한 것으로 마킹되는 것은, 함수가 호출되고 있을 때 어떤 상태에 있는지에 무관하게, 그 함수가 실행하는 것을 허용한다. 예를 들면, 하기에서 추가로 설명되는 바와 같이, API를 안전 API로서 마킹하기 위해, API 정의 단계 동안 태그 및/또는 속성이 API에 할당될 수 있다. 이중성 객체에서, 허용된 및/또는 허용되지 않은 API의 강화는 이중성 객체의 레이아웃 엔진 측 상에서 발생할 수 있다.

안전 API ID를 설명하였지만, 이제, 반사 함수의 논의를 고려한다.

반사 함수

하나 이상의 실시형태에서, 함수의 출처와 관련되는 타입 시스템 정보를 밝히지 않고도, 하나 이상의 도메인에 걸쳐 함수 객체가 리턴될 수 있다. 함수 객체는 함수로 래핑될 수 있고/있거나 프록시 객체와 관련될 수 있는데, 이 경우 래핑된 함수 및/또는 관련 프록시 객체는 다수의 도메인에 걸쳐 리턴된다. 몇몇 실시형태에서, 래핑되지 않은 함수 및/또는 프록시 객체는 수신 도메인의 타입 시스템에서 실현되도록 구성될 수 있다.

하나 이상의 실시형태에서, 함수 객체에 대한 도메인 교차 액세스는, 함수 객체의 출처의 타입 시스템 정보를 밝히지 않고도, 허용될 수 있다. 예를 들면, 제1 도메인에 상주하는 스크립트는 제2 도메인의 함수 객체에 대한 액세스를 요청할 수 있다. 함수 객체는 자신의 출처의 타입 시스템과 관련되는 타입 시스템 정보를 본질적으로(inherently) 포함한다. 이 본질적인 타입 시스템 정보는, 예컨대 래퍼 함수 및/또는 프록시 객체의 사용을 통해, 외부 도메인 및/또는 타입 시스템에게는 가려질 수 있다. 함수 객체가 도메인에 걸쳐 요청되면, 함수 객체 대신 래퍼 함수 및/또는 프록시 객체가 리턴될 수 있다. 래퍼 함수 및/또는 프록시 객체는 또한 호출을 함수 객체로 지향시키도록 구성될 수 있고, 따라서 함수 객체에 대한 간접 액세스를 가능하게 한다. 예를 들면, 래퍼 함수 및/또는 프록시 객체는, 호출, 적용, 바인딩, 생성자 등과 같은 함수 객체의 관련 성능의 전체에 대한 안전한 액세스를 허용할 수 있다.

몇몇 실시형태에서, 래퍼 함수 및/또는 프록시 객체는, 함수 객체의 출처와 관련되는 타입 시스템 정보를 노출시키지 않고도, 호출을 지향시킬 수 있다. 예를 들면, 래퍼 함수 및/또는 프록시 객체는 호출하는 타입 시스템의 타입 시스템에서 인스턴스화하도록(instantiate) 구성될 수 있다. 호출 시스템의 타입 시스템에서 인스턴스화하는 것에 의해, 래퍼 함수 및/또는 프록시 객체의 타입 시스템 정보에 대한 시도된 액세스는 호출 시스템의 타입 시스템 정보를 산출한다. 호출 시스템은, 원래의(original) 함수 객체에 대한 액세스를 위해 호출 시스템에 네이티브한 메소드에서 래퍼 함수 및/또는 프록시 객체를 호출할 수 있다.

래퍼 함수 및/또는 프록시 객체의 사용을 통해, 함수 객체는, 함수 객체와 관련되는 어떠한 타입 시스템 정보도 노출하지 않고도, 다수의 도메인에 걸쳐 액세스될 수 있다. 반사 함수를 논의하였지만, 이제, 서브 윈도우 프록시의 논의를 고려한다.

서브 윈도우 프록시

하나 이상의 실시형태에서, 하나 이상의 서브 윈도우 프록시는 주 타입 시스템 윈도우 프록시와 관련될 수 있다. 서브 윈도우 프록시는 주 윈도우 프록시와 관련되는 적어도 몇몇 보안 정책을 어써트(assert)하도록 구성될 수 있다. 대안적으로 또는 추가적으로, 서브 윈도우 프록시는 주 윈도우 프록시에 관계없이 존재할 수 있다.

때때로, 윈도우 프록시와 관련되는 윈도우는, 액세스가능한 윈도우 아래에 객체를 구비할 수 있다. 윈도우 프록시는 관련 윈도우에 대한 다수의 도메인 액세스를 가능하게 한다. 예를 들면, 윈도우 프록시는, 비제한적인 예로서, 특성 검출, 내장형 판독/기록/실행 요청, 유저 정의 특성 판독/기록/실행 요청, 라이브러리 객체 액세스, 어레이 인덱스 주소지정(addressing), 커스텀 이름 변환(custom name resolution), 열거(enumeration) 등을 관련 윈도우에 프록시할 수 있다. 몇몇 실시형태에서, 윈도우 아래의 객체는, 예컨대 서브 윈도우 프록시를 통해 액세스될 수 있다. 예를 들면, 상기에서 설명된 바와 같은 안전 API로부터 리턴되는 객체는 서브 윈도우 프록시로서 리턴될 수 있다. 프록시 윈도우의 경우에서와 같이, 서브 윈도우 프록시는 자신의 대응하는 객체의 능력을 프록시하도록 구성될 수 있다.

몇몇 실시형태에서, 서브 윈도우 프록시는 자신의 주 윈도우 프록시와 관련되는 적어도 보안 정책을 어써트할 수 있다. 예를 들면, 서브 윈도우 프록시는 보안 결정을 자신의 주 윈도우 프록시에게 맡기도록 구성될 수 있다. 대안적으로 또는 추가적으로, 서브 윈도우 프록시는 자신의 주 윈도우 프록시에 관계없이 존재할 수 있다. 몇몇 실시형태에서, 서브 윈도우 프록시는 새로운 윈도우의 서브 객체의 컨텐츠를 반영하도록 동적으로 업데이트되도록 구성될 수 있다.

따라서, 서브 윈도우 프록시는 윈도우와 관련되는 서브 객체인 객체에 대한 도메인 교차 액세스를, 그 서브 객체와 관련되는 타입 시스템 정보를 노출시키지 않고도, 가능하게 할 수 있다. 서브 윈도우 프록시를 설명하였지만, 이제, 동일 출처 요청에 대한 전역적(global) 최적화의 논의를 고려한다.

동일 출처 요청에 대한 전역적 최적화

많은 웹사이트는, 그들이 글로벌 네임스페이스 루트(global namespace root), 예를 들면, "window.document"에게 특성을 요청하고 있다는 것을 명시적으로 특정하기 위해 자기 참조적 특성을 사용하는데, 여기서 "window"는 네임스페이스 루트 객체에 대한 자기참조이다. 하나 이상의 실시형태에서, 한 글로벌 객체, 예컨대 자바스크립트 글로벌 객체에 대한 자기참조적 특성은, 그 글로벌 객체의 우연한 또는 고의의 개시를 보호하기 위해, 그 객체로 모든 프록시를 리턴한다. 그러나, 자기 참조의 일반적인 관행으로 인해, 보안 체크는 그들이 실제로 필요하지 않은 경우에도 성능을 저하시킬 수 있다. 하나 이상의 실시형태에 따르면, 이들 상황 하에서의 특성 요청의 성능을 강화하기 위해, 프록시의 호출자 및 타겟은 이들이 동일한 객체인지를 검사하도록 우선적으로 체크된다. 만약 그렇다면, 비용이 많이 드는 보안 체크는 글로벌 객체의 보안을 희생하지 않으면서 안전하게 바이패스될 수 있다.

이와 같이, 다양한 실시형태는, 예컨대 호출자 및 타겟이 동일한 도메인 및/또는 출처를 가질 때, 보안 체크가 바이패스되는 것을 가능하게 할 수 있다. 호출자 및 타겟이 동일한 도메인에 존재하면, 보안 체크, 예컨대 도메인 교차 액세스를 보호하기 위한 보안 체크는 바이패스될 수 있다.

한 예로서, 다음의 것을 고려한다. 보안 윈도우 객체, 예컨대 프록시 객체가 활용될 수 있고 글로벌 객체를 소환할 수 있는데, 글로벌 객체는, 결국에는, 다양한 형태의 정보 및/또는 코드 실행, 예컨대 신뢰된 윈도우에 액세스할 수 있다. 이들 호출에 응답하여, 보안 윈도우 객체의 호출자와 호출의 타겟, 예컨대 신뢰된 윈도우가 동일한 도메인 및/또는 출처에 존재하는지의 여부를 결정하기 위한 비교가 이루어질 수 있다. 호출자 및 타겟이 동일한 출처에 존재하는 것으로 결정되면, 보안 체크는 바이패스될 수 있다. 이 경우, 보안 체크를 바이패스하는 것은 의도치 않은 노출의 위험 없이 수행될 수 있다.

동일한 출처의 트랜잭션에 대한 보안 체크를 바이패스하는 것은, 불필요한 코드가 실행하는 것을 방지하는 것에 의해 런타임 성능을 향상시킬 수 있다. 동일 출처 요청에 대한 전역적 최적화를 설명하였지만, 이제, 하나 이상의 실시형태에 따른 예시적인 방법을 고려한다.

도 18은, 하나 이상의 실시형태에 따른 방법에서의 단계를 설명하는 흐름도를 예시한다. 방법은 임의의 적절한 하드웨어, 소프트웨어, 펌웨어, 또는 이들의 조합에 의해 수행될 수 있다. 적어도 몇몇 실시형태에서, 방법의 양태는, 도 1의 보안 모듈(118), 레이아웃 엔진(112), 및/또는 스크립팅 엔진(118)과 같은 컴퓨팅 디바이스 상에서 실행하는 적절히 구성된 소프트웨어에 의해 수행된다.

단계 1800은 레이아웃 엔진 객체를 생성한다. 레이아웃 엔진 객체의 생성은 임의의 적절한 방식으로 수행될 수 있다. 임의의 적절한 타입의 레이아웃 브젝트가 생성될 수 있는데, 이들의 예는 상기에서 제공되어 있다. 단계 1802는 스크립팅 언어 객체, 예컨대 스크립팅 엔진 메모리 공간에 네이티브한 객체를 생성한다. 단계 1804는 레이아웃 엔진 객체 및/또는 스크립팅 언어 객체에 대한 액세스 동안 보안 정보 전송을 제공하는 보안 모델을 사용하는데, 이들의 예는 상기에서 제공되어 있다.

하나 이상의 실시형태에 따른 다양한 보안 모델을 설명하였지만, 이제, 하나 이상의 실시형태에 따른 인터페이스 정의 언어(IDL) 통합의 다양한 양태의 논의를 고려한다.

인터페이스 정의 언어 통합

하나 이상의 실시형태에서, 인터페이스 정의 언어(IDL)에 대한 확장은 레이아웃 엔진 및 스크립팅 엔진의 직접적인 통합을 용이하게 하고 가능하게 할 수 있다.

하나 이상의 실시형태에서, 레이아웃 엔진과 스크립팅 엔진을 중개하도록 구성되는 코드의 생성을 가능하게 하기 위해, 확장 IDL 코드가 IDL 컴파일러와 연계하여 사용될 수 있다. 대안적으로 또는 추가적으로, 객체와 그들의 관련 API 사이의 계층적 관계가 확장 IDL을 사용하여 설명될 수 있다. 몇몇 실시형태에서, 확장 IDL은 객체 및/또는 관련 API의 속성을 설명하는 구문을 포함할 수 있다.

당업자에 의해 인식되는 바와 같이, 다양한 소프트웨어 컴포넌트 사이의 하나 이상의 인터페이스, 예컨대 레이아웃 엔진과 스크립팅 엔진 사이의 인터페이스를 설명하기 위해, IDL 코드가 사용될 수 있다. IDL 코드에 대한 확장은, 본원에서 설명된 바와 같이, 객체, 객체 상에서 정의되는 API, 객체 사이의 관계, 객체 및/또는 API와 관련되는 속성 등을 추가로 설명하기 위해 포함될 수 있다. 컴파일러, 예컨대 IDL 컴파일러는 IDL 코드를 해석하고 대응하는 함수, 헤더 파일 등을 생성하여, 소프트웨어 컴포넌트의 서로에 대한 액세스를 가능하게 할 수 있다.

예로서, 확장 IDL 코드, 컴파일러, 및 관련 입력 및 출력 사이의 관계를 예시하는 도 19를 고려한다. 여기서는, 하기에서 더 상세히 설명되는 트램펄린 함수(들)(1908), 트램펄린 정의(들)(1910) 및 타입별 초기화 함수(들)(1912)를 생성하기 위해, 컴파일러(1906)에 의해 특성 설명 언어(Property Description Language; PDL) 파일(들)(1902) 및 확장 IDL 파일(1904)이 수신되어 프로세싱된다.

예시되고 설명된 실시형태에서, PDL 파일(1902)은, 하나 이상의 레이아웃 엔진 프로그래밍 객체 및/또는 그들의 관련 API를 정의하는 하나 이상의 파일을 포함할 수 있다. PDL 파일을 통해, 임의의 적절한 타입의 프로그래밍 객체, 예컨대, 비제한적인 예로서, COM 기반 객체가 정의될 수 있다. 몇몇 실시형태에서, PDL 파일(1902)은 하나 이상의 스크립팅 언어 객체, 예컨대 디스패치 객체를 정의하는 하나 이상의 파일을 포함할 수 있다. 디스패치 객체는 스크립팅 엔진이 동적 바인딩을 통해, 예컨대 디스패치 방법을 통해, 레이아웃 엔진 객체로부터의 객체를 룩업하고/하거나 레이아웃 엔진 객체로부터 객체획득하는 것을 가능하게 한다.

하나 이상의 실시형태에서, 확장 IDL 파일(1904)은, PDL 파일(1904)에 포함되는 API 및 객체 중 적어도 몇몇의 대안적인 설명을 포함한다. 몇몇 실시형태에서, 이들 대안적인 설명을 표현하기 위해, 확장 특성 설명 언어(extended property description language) 및/또는 확장 인터페이스 정의 인터페이스 언어(extended interface definition interface language)가 사용된다. 예를 들면, 확장 언어는, 하기에서 추가로 설명되는 바와 같이, API 및/또는 객체에 적용될 수 있는 추가적인 속성을 포함할 수 있다. 속성을 포함하는 것 외에, 확장 IDL 파일(1904)은 계층적 관계 정보, 예컨대 API의 계층적 배치를 포함할 수 있다. API는 계층적 정보에 기초하여 객체로서 배치될 수 있고, 따라서 확장 IDL 파일(1904) 없이 PDL 파일(들)(1902)을 사용하는 것으로부터 생성될 중복성을 감소시키고/시키거나 제거하게 된다.

예시되고 설명된 실시형태에서, 컴파일러(1906)는 다수의 입력 파일, 예컨대 PDL 파일(들)(1902) 및 확장 IDL 파일(1904)을 수용하고, 이들 파일을 프로세싱하여 트램펄린 함수(들)(1908), 트램펄린 정의(들)(1910), 타입별 초기화 함수(들)(1912)를 생성한다. 도 19에서 하나의 모듈로서 예시되지만, 컴파일러(1906)는 다수의 모듈을 포함할 수 있다는 것이 인식되고 이해되어야 한다.

하나 이상의 실시형태에서, 트램펄린 함수(1908)는, 소프트웨어 모듈 사이의 호출이 중개되는 것을 가능하게 하는 코드, 예컨대 상기 설명된 바와 같은 동적 타입 시스템 다이렉트 함수를 포함한다. 몇몇 실시형태에서, 트램펄린 함수(1908)는 소스 코드, 예컨대 C++ 구현 파일(.cpp 파일)로서 생성될 수 있다. 물론, 청구되는 주제의 범위를 벗어나지 않으면서, 다른 코드 타입이 생성될 수 있다. 트램펄린 함수(1908)는 컴파일러(1906)에 의해 부분적으로 또는 완전히 생성될 수 있다.

트램펄린 함수(들)(1908) 외에, 컴파일러(1906)는 트램펄린 정의(들)(1910)를 생성할 수 있다. 트램펄린 정의(들)(1910)는 하나 이상의 정의 및/또는 관련 트램펄린 함수(들)(1908)의 전방 선언(forward declaration), 예컨대 헤더 파일(.h 파일)에 포함되는 전방 선언을 포함할 수 있다.

몇몇 실시형태에서, 타입별 초기화 함수(1912)는 스크립팅 언어로 씌여진 명령어 및/또는 스크립트, 예컨대 자바스크립트를 포함하고 타입 시스템의 하나 이상의 타입의 초기화, 예를 들면, 상기에서 설명된 바와 같은 동적 타입 시스템 지연 초기화를 가능하게 한다.

예컨대 객체 관계 정보를 통해 코드 중복성을 감소시키고/시키거나 제거하는 것 외에, PDL 파일(들)(1902) 및 확장 IDL 파일(1904)의 조합 사용은, 결과적으로 나타나는 코드가, 추가적인 컴파일 이전에, 사람에 의해 검사가능하게 되는 것을 가능하게 한다. 예를 들면, 개발자는 확장 IDL 파일(1904) 내에 속성을 추가하고, 삭제하고, 및/또는 수정하고, 그 수정을 컴파일러(1906)에게 입력하고, 결과적으로 나타나는 소스 코드 파일(들)을 이진 코드를 생성하기 이전에 검사할 수 있다. 이 상호작용식 프로세스는 소프트웨어 결함이 개발 싸이클에서 더 빨리 위치결정되는 것을 가능하게 할 수 있다.

PDL 및 확장 IDL 파일 및 이들이 컴파일러에 의해 어떻게 프로세싱되는지를 설명하였지만, 이제, 하나 이상의 실시형태에 따른 예시적인 확장 IDL 파일의 논의를 고려한다.

도 20은, 예를 들면, 도 1의 확장 IDL 파일(120)과 같은 확장 IDL 파일에 포함될 수 있는 확장의 확대도를 예시한다. 도 20이 피쳐 및/또는 속성의 조합을 포함하는 확장 IDL 파일(120)을 예시하지만, 청구되는 주제로부터 벗어나지 않으면서, 속성의 임의의 조합이 포함될 수 있고/있거나 배제될 수 있다는 것이 인식되고 이해되어야 한다.

이 특정한 예에서, 확장 IDL 파일(120)은 하나 이상의 주석/다큐먼트화 속성(annotation/documentation attribute; 2002), 하나 이상의 글로벌 객체 확장 속성(global object extension attribute; 2004), 하나 이상의 코드 생성 속성(2006), 및/또는 하나 이상의 API 이용가능성 속성(API availability attributes; 2008)을 포함하는데, 이들 각각은 하기에서 개별적으로 논의된다.

하나 이상의 실시형태에서, 주석/다큐먼트화 속성(2002)은 다양한 형태의 추가적인 주석 및/또는 다큐먼트화가 확장 IDL 파일(120) 및/또는 관련 출력 파일에 포함되는 것을 가능하게 한다. 몇몇 주석 속성은, 예컨대 유니폼 리소스 로케이터(Uniform Resource Locator; URL)를 포함하는 것에 의해 하이퍼 링크를 위해 사용될 수 있다. 예를 들면, 속성은 인터페이스 및/또는 특성 정의와 관련되는 링크, 예컨대 인터페이스 및/또는 특성 정의에 대한 관련 명세 및/또는 추가적인 다큐먼트화를 포함할 수 있다. 링크를 설명하기 위해, 및/또는 인터페이스 및 특성 정의를 관련 이진 코드 표현으로 나타내기 위해, 다른 주석 속성이 사용될 수 있다. 몇몇 실시형태에서, 주석 속성은, 릴리스 정보(release information), 예컨대 API 도입 날짜 및/또는 시간, 수정 날짜 및/또는 시간, 저작자(author), 개정 번호(revision number) 등을 포함하도록 사용될 수 있다. 대안적으로 또는 추가적으로, 주석 속성은 관련 속성 이름을 갖는 특성 및/또는 캐스캐이드형 스타일 시트(Cascading Style Sheet; CSS) 특성을 확장하기 위해 사용되는 속성을 포함할 수 있다. 예를 들면, 몇몇 실시형태에서, 속성의 대안적인 언어 이름을 포함하기 위해, 주석 속성이 사용될 수 있다. 테스트용 ID 기준(identification reference), 예컨대 관련 API의 공공 테스트 스위트(public test suite)를 조정하기 위해 사용될 수 있는 테스트용 ID 기준을 포함하기 위해, 다른 주석 속성이 사용될 수 있다. 하나 이상의 실시형태에서, API 분류 및 검색 인덱싱을 가능하게 하는 태그 식별자를 포함하기 위해, 주석 속성이 사용될 수 있다.

하나 이상의 실시형태에서, 글로벌 객체 확장 속성(2004)은, 스크립팅 엔진의 글로벌 객체를 확장하기 위해 어떤 인터페이스가 사용될 수 있는지의 제어를 가능하게 한다. 예를 들면, 글로벌 객체 확장 속성(2004)은 글로벌 객체로서 접목될 하나 이상의 인터페이스를 식별할 수 있다. 이것은 대안적 형태의 확장 IDL 파일(120)의 존재가, 상이한 글로벌 객체 통합을 지원하는 것을 가능하게 할 수 있다.

하나 이상의 실시형태에서, 코드 생성 속성(2006)은 코드가 생성되는 방식의 제어를 가능하게 한다. 예를 들면, 특성 및/또는 API를 상기 설명된 바와 같은 안전 API로 마킹하는 것과 같은, 특성 및/또는 API의 보안 양태를 제어하기 위해, 몇몇 속성이 사용될 수 있다. 락다운(locked-down)되도록, 비가변성이 되도록, 열거가능하지 않도록, 및/또는 구성가능하지 않도록 특성을 구성하는 것과 같은, 특성의 디폴트 초기화를 제어하기 위해 다른 속성이 사용될 수 있다. 속성의 사용을 통해, 특성은 서로 독립적으로 구성될 수 있다. 예를 들면, 확장 IDL 파일(120)에서 설명되는 제1 특성은 가변적이도록 구성될 수 있고, 한편 확장 IDL 파일(120)에서의 제2 특성은 비가변적이도록 구성될 수 있다.

대안적으로 또는 추가적으로, 관련 코드에 대한 엔트리 포인트를 나타내기 위해 속성이 사용될 수 있다. 예를 들면, C++ 엔트리 포인트를 설명하기 위해 속성이 사용될 수 있다. 옵션적인(optional) 전달 파라미터(pass-in parameter)에 대해 사용될 디폴트 값을 나타내기 위해 다른 속성이 사용될 수 있다.

하나 이상의 실시형태에서, API 이용가능성 속성(2008)은 현재의 환경에 기초하여 API 이용가능성의 구성을 가능하게 한다. 예를 들면, 하나 이상의 API가 하이퍼텍스트 마크업 언어(HyperText Markup Language; HTML)를 실행하는 웹 페이지에 대해 이용가능하게 되는 것을 가능하게 하기 위해, 그러나, 확장성 마크업 언어(extensible Markup Language; XML)를 실행하는 웹 페이지에 대해 이용불가능하게 되는 것을 가능하게 하기 위해, 속성이 사용될 수 있다. 몇몇 실시형태에서, API를 향후 지원되지 않을 것(deprecated)으로 마킹하기 위해 속성이 사용될 수 있는데, 이것은 XML 기반 페이지 하에서 API의 제거를 트리거할 수 있다.

IDL 파일에 포함될 수 있는 다양한 확장을 설명하였지만, 이제, 하나 이상의 실시형태에 따른 방법에서의 단계를 설명하는 흐름도를 예시하는 도 21을 고려한다. 방법은 임의의 적절한 하드웨어, 소프트웨어, 펌웨어, 또는 이들의 조합에 의해 수행될 수 있다. 적어도 몇몇 실시형태에서, 방법의 몇몇 양태는 컴퓨팅 디바이스 상에서 실행하는 소프트웨어에 의해 수행된다.

단계 2100은 하나 이상의 특성 설명 언어(PDL) 파일을 수신하는데, 이들의 예는 상기에서 제공되고 있다. 단계 2102는 적어도 하나의 확장 인터페이스 정의 언어(IDL) 파일을 수신한다. 상기에서 설명된 바와 같이, 확장 IDL 파일은, 확장 속성, 예컨대 주석 속성, 글로벌 객체 확장 속성 등의 임의의 적절한 조합을 포함할 수 있다. 단계 2104는 PDL 파일 및 확장 IDL 파일을 프로세싱하여 적어도 하나의 헤더 파일 및 관련 소스 코드 파일을 생성한다. 헤더 파일 및 관련 소스 코드 파일은, 예컨대 다이렉트 타입 시스템 다이렉트 함수를 통해, 스크립팅 엔진과 레이아웃 엔진의 바인딩을 가능하게 하도록 구성된다. 단계 2016은 PDL 파일 및 확장 IDL 파일을 프로세싱하여 적어도 하나의 타입 시스템 초기화 함수를 생성한다. 타입 시스템 초기화 함수는, 예컨대 상기에서 설명된 바와 같은 동적 타입 시스템 지연 초기화를 통해, 스크립팅 엔진 및 레이아웃 엔진의 바인딩을 가능하게 하도록 구성될 수 있다.

인터페이스 정의 언어 통합을 설명하였지만, 이제, 하나 이상의 실시형태에 따른 스크립팅 엔진과 레이아웃 엔진 사이의 대안적 액세스의 논의를 고려한다.

스크립팅 엔진과 레이아웃 엔진 사이의 대안적 액세스

앞서 설명된 바와 같이, 스크립팅 엔진 및 레이아웃 엔진은, 다른 것들 중에서도, 웹 페이지, 웹 컨텐츠 등을 프로세싱하고/하거나 렌더링하기 위해 연계하여 사용될 수 있다. 이들 엔진이 별개의 환경 및/또는 메모리 공간에서 실행하면, 별개의 환경 사이의 교차는 통상적으로, 동일한 환경에서 발생하는 상호작용보다 더 많은 프로세싱을 수반한다. 상기에서 설명되는 다양한 기술의 사용을 통해, 도메인 교차 상호작용 및/또는 환경 교차 상호작용이 더 가깝게 커플링될 수 있고, 이것은, 결국에는, 도메인 사이의 액세스를 더 효율적으로 만들 수 있다. 이것은, 결국에는, 스크립팅 엔진 및/또는 레이아웃 엔진에 의해 사용되는 프로세싱의 양을 감소시킬 수 있고, 하나의 또는 둘 다의 엔진과 관련되는 제품의 유저의 전체적인 인식을 더 향상시킬 수 있다. 예를 들면, 상기에서 설명된 트램펄린 함수는 스크립팅 엔진과 레이아웃 엔진 사이에 논리적으로 개재되며, 스크립팅 엔진 및 레이아웃 엔진이 서로 간에 기능성을 전달하고 호출하는 효율적인 방식을 제공한다. 그러나, 트램펄린 함수를 호출하는 것은 몇몇 도메인 교차 통신 및/또는 환경 교차 통신을 여전히 필요로 한다. 이와 같이, 트램펄린 함수를 반복적으로 호출하는 것은, 런타임 성능이 둔화하도록 영향을 끼칠 수 있다.

몇몇 실시형태에서, 스크립팅 엔진의 메모리 공간은 하나 이상의 레이아웃 엔진 객체, 예컨대 상기에서 설명된 바와 같은 CustomExternalObject의 설명(들)을 포함한다. 대안적으로 또는 추가적으로, 스크립팅 엔진의 메모리 공간은 레이아웃 엔진 객체(들)와 관련되는 하나 이상의 특성 객체의 설명을 포함할 수 있다. 때때로, 스크립팅 엔진 메모리 공간 내에 포함되는 특성 객체의 설명(들)은, 스크립팅 엔진 메모리 공간 내에서 설명되는 하나 이상의 대응하는 레이아웃 엔진 객체와, 스크립팅 엔진 메모리 공간에서, 관련될 수 있다. 몇몇 실시형태에서, 스크립팅 엔진 메모리 공간 내에서의 특성 객체 및/또는 관련 기능성은, 레이아웃 엔진의 메모리 공간 안으로 교차하지 않고도, 스크립팅 엔진 메모리 공간 내에서부터 액세스될 수 있다.

도 4와 관련된 상기 논의를 다시 참조하여, var 객체(414 및 416)를 고려한다. 각각의 var 객체는, 스크립팅 엔진 메모리 공간에 존재하는 이중성 객체를 나타내며, 레이아웃 엔진 메모리 공간에 존재하는 레이아웃 엔진 객체에 바인딩된다. 여기서, var 객체(414 및 416)는 CBase 객체(402 및 404)에 각각 바인딩된다. 몇몇 실시형태에서, CBase 객체(402 및 404)의 특성은, 액세서 메소드, 예컨대 세터 액세서 메소드 및/또는 게터 액세서 메소드를 관련시킨 객체로서 구현된다. 상기에서 논의된 바와 같이, 이들 액세서 메소드는 스크립팅 엔진에 네이티브한 방식으로 스크립팅 엔진에 노출될 수 있고, 한편, 특성 객체 자체와 관련되는 메모리 위치는 호출하는 엔티티에게 알려지지 않은 상태로 유지된다. 예를 들면, 윈도우에서의 다큐먼트 특성을 고려한다. 이 특성을 취출하기 위해, 유저는 다음과 유사한 코드를 작성할 수 있을 것이다:

var myDocument = window.document

여기서, 스크립팅 엔진은 "window" 객체의 지식을 가지고 있고 게터 액세서 "document"를 사용하여 윈도우 객체로부터 다큐먼트 특성 객체를 취출할 수 있다. 여기서, "window"는 상기에서 설명된 바와 같은 기술을 사용하여 스크립팅 엔진의 메모리 공간 내에서 설명된다. 마찬가지로, 취출된 다큐먼트 특성 객체(예를 들면, "myDocument")를 저장하기 위해, 스크립팅 엔진 메모리 공간에서 새로운 var가 생성된다. 게터 액세서 메소드가 스크립팅 엔진에 네이티브한 방식으로 표현되지만, (상기에서 논의된 바와 같은) 몇몇 실시형태는 다이렉트 함수를 사용하고, 이것은, 결국에는, 스크립팅 엔진 메모리 공간으로부터 레이아웃 엔진 메모리 공간으로 교차하기 위해 트램펄린 함수를 사용한다. 따라서, 액세서 함수가 스크립팅 엔진에 네이티브한 방식으로 스크립팅 엔진에 노출되는 동안, 액세서 함수 호출은 시간 소모적일 수 있는 메모리 공간 경계 사이를 넘어간다.

몇몇 실시형태는 스크립팅 엔진 메모리 공간 내의 하나 이상의 특성 객체의 표현을 스크립팅 엔진 메모리 공간 내에 표현되는 하나 이상의 부모 객체에 관련시킨다. 스크립팅 엔진 메모리 공간 내에서 이들 관련성을 생성하고/하거나 유지하는 것에 의해, 스크립팅 엔진에서 실행하는 스크립트는, 레이아웃 엔진의 메모리 공간 안으로 넘어가지 않으면서 부모 객체의 특성 객체에 액세스할 수 있다.

추가로 예시하기 위해, 하나 이상의 실시형태에 따라 다수의 객체 관계를 메모리 모델에 저장하는 도 22를 고려한다. 이 도면에서, 하기에 추가로 설명되는 바와 같이, 객체 관계(2202)는 특성 객체가 액세서 및 다이렉트 함수의 사용을 통해 액세스되는 객체 관계를 나타내고, 한편 객체 관계(2204)는 특성 객체가 관련성의 사용을 통해 액세스되는 대안적인 객체 관계를 나타낸다. 상기 코딩 예를 참조하면, 각각의 객체 관계 다이어그램은 상기의 window.documnt 코딩 예를 설명하는 상이한 액세스 모델을 나타낸다.

var 객체(2206a)는 스크립팅 엔진 메모리 공간에서의 "window" 객체를 나타낸다. 상기에서 설명된 바와 같이, var 객체(2206a)는, 자신의 레이아웃 엔진 객체 대응부가 윈도우 객체(2208a)에 의해 나타내어지는 이중성 객체이다. 몇몇 실시형태에서, var 객체(2206a)는 CustomExternalObject를 통해 스크립팅 엔진 메모리 공간에서 설명되는 객체가고, (여기서는 점선에 의해 나타내어지는) 앞서 설명된 바와 같은 윈도우 객체(2208a)에 대한 유사한 링키지를 갖는다. 상기 예에서, "window"의 다큐먼트 특성은 "getElementld" 게터 액세서를 호출하는 것에 의해 액세스된다. 이 게터 액세서가 호출되면, 플로우(2210)에 의해 예시된 바와 같이, 스크립트의 실행은 스크립팅 엔진 메모리 공간으로부터의 요청을 레이아웃 엔진 스크립팅 공간 안으로 넘기고/넘기거나 마셜링한다. 결국에는, 윈도우 객체(2208a)는 다큐먼트 특성 객체(2212a)를 취출하고, 데이터를 다시 스크립팅 엔진 메모리 공간 안으로 마셜링하는데, 여기서는 플로우(2214)에 의해 예시된다. 상기의 코딩 예의 구문을 사용하여, 리턴된 데이터는, 그 다음, var 객체(2216a)를 통해 스크립팅 엔진 메모리 안에 저장된다. var 객체(2206a)와 윈도우 객체(2208a) 사이에 링키지가 존재하지만, var 객체(2206a)는, 게터 액세서가 호출되고 데이터가 레이아웃 엔진 메모리 공간으로부터 리턴될 때까지, var 객체(2216a)의 지식 및/또는 링키지를 갖지 않는다.

이제, 객체 관계(2204)를 고려한다. 객체 관계(2202)의 경우에서와 같이, 객체 관계(2204)는 var 객체(2206b) 및 윈도우 객체(2208b)를 포함하는데, 이들은 이중성 객체를 포함한다. 객체 관계(2204)는 또한 var 객체(2216b) 및 다큐먼트 특성 객체(2212b)를 포함하는데, 여기서, 상기의 경우에서와 같이, 다큐먼트 특성 객체(2212b)는 윈도우 객체(2208b)의 특성이다. 여기서, var 객체(2216b) 및 다큐먼트 특성 객체(2212b)는 서로 사이에 (점선에 의해 나타내어진) 링키지를 갖는 것으로 예시된다. 그러나, 객체 관계(2202)와는 대조적으로, var 객체(2206b)와 var 객체(2216b) 사이에 링키지(2218)가 존재한다. 스크립팅 엔진 메모리에서 var 객체(2216b)가 어디에 있는지의 지식을 var 객체(2206b)가 가지기 때문에, var 객체(2216b)는 스크립팅 엔진 메모리 공간 내에서부터, 그리고 레이아웃 엔진 메모리 공간 안으로 넘어가지 않으면서, var 객체(2206b)에 의해 직접적으로 액세스될 수 있다. 이 예가 게터 액세서의 맥락(context) 내에서 설명되지만, 청구되는 주제의 범위를 벗어나지 않으면서 세터 액세서가 활용될 수 있을 것이라는 것이 인식되고 이해되어야 한다.

몇몇 실시형태에서, 특성 객체의 스크립팅 엔진 메모리 공간 표현은 스크립팅 엔진 메모리 공간 내에서 설명되는 부모 객체와 관련될 수 있다. 그 다음, 부모 객체는, 특성 객체의 지식을 획득하기 위해 레이아웃 엔진 메모리 공간 안으로 넘어가지 않으면서 스크립팅 엔진 메모리 공간 내에서부터 특성 객체의 스크립팅 엔진 메모리 공간 표현에 액세스할 수 있다. 예를 들면, 하나 이상의 특성 객체는 직접적으로 저장될 수 있고/있거나 부모 객체의 스크립팅 엔진 표현과 관련되는 구조와 관련될 수 있다.

상기에서 설명된 것과 유사한 예시적인 CustomExternalObject와 대안적인 실시형태 사이의 비교를 예시하는 도 23을 고려한다. 시작하기 위해, 도 23은 도 5의 CustomExternalObject(500)를 포함한다. 상기에서 설명된 바와 같이, CustomExternalObject(500)는, 이중성 객체와 관련될 수 있는 스크립팅 언어 객체, 또는 var를 나타낸다. CustomExternalObject(500)는 이중성 객체와 관련되는 다양한 관계 포인터, 예컨대 자식 포인터, 부모 포인터 등을 포함한다. 몇몇 실시형태에서, CustomExternalObject(500)는, 하기에서 추가로 설명되는 바와 같이, 하나 이상의 특성 객체를 포함하도록 확장될 수 있다.

CustomExternalObject(2300)는 CustomExternalObject(500)의 확장 버전을 나타낸다. 완전히 예시되지는 않지만, CustomExternalObject(2300)는 CustomExternalObject(500)를 참조로 설명된 것들과 동일한 세트의 포인터(예를 들면, 부모 포인터, 자식 포인터, 이전 포인터(previous pointer) 등)를 포함한다. 이들 앞서 설명된 포인터 외에, CustomExternalObject(2300)는 미리 정의된 포인터 슬롯(2302, 2304, 및 2306)을 포함한다. 다른 것들 중에서도, 미리 정의된 포인터 슬롯(2302, 2304, 및/또는 2306) 각각은 스크립팅 엔진 메모리 공간에서 설명되는 var 객체 예컨대 특성 객체에 대한 포인터를 포함할 수 있다. 여기서, CustomExternalObject(2300)는 "N"개의 미리 정의된 포인터 슬롯을 포함하는 것으로 예시된다. 그러나, "N"개는 임의의 수를 나타내기 위해 단지 예시적인 목적으로 사용되는 것이라는 것이 인식되어야 한다. 예를 들면, CustomExternalObject(2300)는 한 개의 미리 정의된 포인터 슬롯을, 10개의 미리 정의된 포인터 슬롯을, 등을 포함할 수 있다. 따라서, 청구되는 주제의 범위를 벗어나지 않으면서 임의의 수의 미리 정의된 포인터 슬롯이 사용될 수 있다.

이제, 대안적인 및/또는 확장 CustomExternalObject(예컨대 도 23의 CustomExternalObject(2300)) 내에 포함되는 미리 정의된 포인터 슬롯이 하나 이상의 실시형태에 따라 어떻게 활용될 수 있는지를 예시하는 도 24를 고려한다. 도 24는 두 개의 CustomExternalObject - CustomExternalObject(2402 및 2404) - 를 예시하는데, 그 각각은 스크립팅 엔진을 통해 생성되는 var 객체를 나타낸다. 여기서, CustomExternalObject(2402 및 2404)는, 각각, "N" 개의 수의 그리고 "M" 개의 수의 미리 정의된 포인터 슬롯을 포함하는 것으로 예시된다. 이들 임의적인 값은, 각각의 CustomExternalObject가 서로 상이한 수의 미리 정의된 포인터 슬롯을 포함할 수 있을 뿐만 아니라, 잠재적으로 동일한 수의 미리 정의된 포인터 슬롯을 포함할 수 있다는 것을 예시하기 위해 사용된다. 예를 들면, 몇몇 경우에서, CustomExternalObject(2402)는 하나 이상의 미리 정의된 포인터 슬롯을 포함할 수도 있지만, CustomExternalObject(2404)는 0개 이상의 미리 정의된 포인터 슬롯을 포함한다. 따라서, CustomExternalObject 사이에서의 미리 정의된 포인터 슬롯의 수는 0개에서부터 복수 개까지 변할 수 있다.

몇몇 실시형태에서, 하나의 및/또는 각각의 CustomExternalObject는 대응하는 이중성 객체와 관련된다. 이 특정 예에서, CustomExternalObject(2402)는, 레이아웃 엔진을 통해 생성된 대응하는 윈도우 객체와 관련되고, 한편 CustomExternalObject(2404)는 윈도우 객체의 대응하는 특성 객체와 관련된다. 몇몇 실시형태에서, CustomExternalObject(2402)와 CustomExternalObject(2404) 사이의 관계는 미리 정의된 포인터 슬롯의 사용을 통해 스크립팅 엔진 메모리 공간에서 표현될 수 있다. 여기서, 미리 정의된 포인터 슬롯(2406)은, 링크(2410)에 의해 예시된 바와 같이, CustomExternalObject(2404)의 객체(2408)를 가리키는 포인터를 포함한다. 몇몇 경우에서, 미리 정의된 포인터 슬롯은 특성 객체를 가리키는 것으로 식별될 수 있다. 후속하여, 특성 객체와 관련되는 액세서 함수는 대응하는 미리 정의된 포인터 슬롯에 그에 맞게 액세스하도록 구성될 수 있다.

몇몇 실시형태에서, 스크립팅 엔진은, 확장 CustomExternalObject의 미리 정의된 포인터 슬롯을 활용하고/하거나 액세스하는 게터 액세서 및/또는 세터 액세서를 제공하도록 구성될 수 있다. 예를 들면, (상기에서 논의된 바와 같은) 트램펄린 함수를 통해 레이아웃 엔진 메모리 공간 안으로 넘어가는 다이렉트 함수 및 호출을 사용하도록 구성되는 대신, 객체와 관련되는 게터 액세서는, 대응하는 미리 정의된 포인터 슬롯을 가리키게 되는 및/또는 대응하는 미리 정의된 포인터 슬롯에 저장되는 스크립팅 엔진 메모리 공간 var를 취출하도록 구성될 수 있다. 마찬가지로, 세터 액세서는, 미리 정의된 포인터 슬롯을 가리키게 되는 및/또는 미리 정의된 포인터 슬롯에 저장되는 스크립팅 엔진 메모리 공간 var 객체에 정보를 저장하도록 구성될 수 있다. 몇몇 실시형태에서, 관련 IDL 파일은, 하기에서 추가로 설명되는 바와 같이, 특성과, 관련된 미리 정의된 포인터 슬롯 번호 사이의 하나 이상의 매핑을 포함할 수 있다. 따라서, 액세서와 관련되는 기능성은 스크립팅 엔진 메모리 공간 내의 객체로 지향될 수 있고, 이것은, 결국에는, 실행을 동일한 메모리 공간 내에서 유지하는 것에 의해, 그리고, 메모리 경계를 넘지 않게 하는 것에 의해, 성능을 향상시킬 수 있다. 미리 정의된 포인터 슬롯과 관련되는 특성 객체에 액세스하는 수단으로서 액세서 함수(예컨대 게터/세터 쌍)를 제공하는 것의 하나의 이점은, 액세서 함수를 제공하는 것이 유저에게 추가적인 유연성을 산출한다는 것이다. 예를 들면, 프로그래머는, 스크립팅 엔진에 의해 제공되는 액세서 함수 대신, 유저 특정의 및/또는 유저 고유의 스크립팅 코드를 작성할 수 있고/있거나 스크립팅 엔진에 의해 제공되는 액세서 함수에 유저 특정의 스크립팅 코드를 체인화할 수 있다. 이 기능성은 프로그래머에게 유연성을 제공할 뿐만 아니라, 그것은 특성에 액세스할 때 통합된 특성 객체 모델을 추가적으로 유지한다. 따라서, 레이아웃 엔진 객체와 관련 스크립팅 엔진 객체 사이의 바인딩은, 몇몇 경우에서, 스크립팅 엔진 메모리 공간 내에 존재하고/하거나 유지될 수 있다.

몇몇 실시형태에서, 미리 정의된 포인터 슬롯은 메모리 초기화 이전에 식별된다. 예를 들면, 미리 정의된 포인터 슬롯은 식별 프로세스 동안 식별될 수 있는데, 이 경우 레이아웃 엔진과 관련되는 레이아웃 엔진 및/또는 코드는, 미리 정의된 포인터 슬롯과 관련시킬 객체의 어떤 하나 이상의 특성을 특정한다. 이것은 임의의 적절한 방식으로 행해질 수 있다. 예를 들면, 몇몇 실시형태에서, IDL 속성은, 객체의 모든 특성, 객체의 특성의 서브셋 등과 같이 객체에 대해 얼마나 많은 미리 정의된 포인터 슬롯을 확보할지에 주석을 달기 위해 사용될 수 있다. 대안적으로 또는 추가적으로, 한 객체에 대해 확보되는 미리 정의된 포인터 슬롯의 수는, 그 객체와 관련되는 특성에 대한 슬롯을 확보하는 것뿐만 아니라 하나 이상의 부모 객체 및/또는 노드에 대한 추가 슬롯을 확보하는 것과 같이, 그 객체와 관련되는 계층에 적어도 부분적으로 기초할 수 있다. 따라서, 미리 정의된 포인터 슬롯의 수는 객체와 관련되는 특성에 기초한 카운트뿐만 아니라, 객체의 계층과 관련되는 특성도 포함할 수 있다.

CustomExternalObject가 생성되고/되거나 초기화되면, 미리 정의된 포인터 슬롯은 대응하는 특성 객체를 배정받고 할당받을 수 있다. 상기 코딩 예를 다시 참조하면, IDL을 사용하여 윈도우를 설명할 때, IDL 주석은 윈도우의 다큐먼트 특성을 미리 정의된 포인터 슬롯(예컨대 미리 정의된 포인터 슬롯 "0")과 관련되는 것으로 설명하기 위해 사용될 것이다. 초기화에서, 대응하는 미리 정의된 포인터 슬롯(예컨대 미리 정의된 포인터 슬롯 "0")은 대응하는 다큐먼트 특성 객체에 대한 포인터를 배당받아 할당받을 것이다. 마찬가지로, 대응하는 슬롯 "0" 게터 함수는 대응하는 액세서 함수(예컨대 get Document) 등에 결부될 것이다.

스크립팅 엔진 메모리 공간 내의 특성 객체를, 초기화 동안 스크립팅 엔진 메모리 공간 내에서 또한 설명되는 대응하는 객체에 관련시키는 것은, 도메인 교차 및/또는 환경 교차 액세스를 감소시키는 것에 의해 실행 성능을 향상시킬 수 있다. 몇몇 경우에서, 성능은, 관련 코드가 컴파일되는 방식에 의해 또한 향상될 수 있다. 예를 들면, 특성 객체를 부모 객체와 관련시키기 위해 미리 정의된 슬롯 포인터를 사용하는 것에 의해, 동일한 메모리 공간(예를 들면, 스크립팅 엔진 메모리 공간) 내에 관련 객체뿐만 아니라, 액세서 함수도 또한 포함된다. 따라서, 컴파일러는, 결국에는, 이 지식을 유익하게 사용할 수 있다. 예를 들면, 특성 객체를 취출할 때 더 빠른 실행 성능을 위해, 관련 액세서 코드를 어셈블리 코드로 컴파일 하기 위해 적시(Just-In-Time; JIT) 컴파일러가 사용될 수 있다. JIT 컴파일러가 관련 메모리 어드레스를 알고 있기 때문에, 어셈블리 언어 코드는 특정 메모리 어드레스에 직접적으로 액세스하도록 생성될 수 있고, 따라서 효율적인 코드 실행을 생성하게 된다.

추가적으로 예시하기 위해, 하나 이상의 실시형태에 따른 방법에서의 단계를 설명하는 흐름도를 예시하는 도 25를 고려한다. 방법은 임의의 적절한 하드웨어, 소프트웨어, 펌웨어, 또는 이들의 조합에 의해 수행될 수 있다. 적어도 몇몇 실시형태에서, 방법의 양태는 시스템, 예컨대 도 1 및 도 2에서 예시되는 시스템에 의해 수행된다.

단계 2500은 레이아웃 엔진 객체를 생성한다. 레이아웃 엔진 객체의 생성은 임의의 적절한 방식으로 수행될 수 있다. 임의의 적절한 타입의 레이아웃 엔진 객체가 생성될 수 있는데, 이들의 예는 상기에서 제공되어 있다. 다른 것들 중에서도, 레이아웃 엔진 객체는 레이아웃 엔진 메모리 공간에 네이티브한 객체를 포함한다.

단계 2502는 적어도 하나의 미리 정의된 포인터 슬롯을 갖는 스크립팅 언어 객체를 생성한다. 여기서, 스크립팅 언어 객체는 스크립팅 엔진 메모리 공간에 네이티브한 객체를 나타낸다. 몇몇 경우에서, 스크립팅 언어 객체 및 레이아웃 엔진 객체는 이중성 객체를 포함한다. 스크립팅 언어 객체의 생성은 임의의 적절한 방식으로 수행될 수 있는데, 이들의 예는 상기에서 제공되어 있다. 몇몇 실시형태에서, 미리 정의된 포인터 슬롯은 스크립팅 엔진 메모리 공간에 네이티브한 다른 객체에 대한 포인터를 포함하도록 및/또는 그 다른 객체를 가리키도록 구성된다. 대안적으로 또는 추가적으로, 미리 정의된 포인터 슬롯은, 스크립팅 엔진 메모리 공간에 완전히 네이티브한 객체를 포함하도록 구성될 수 있다. 또한, 스크립팅 언어 객체 내에 포함되는 미리 정의된 포인터 슬롯의 수는, 스크립팅 언어 객체와 관련되는 계층에 적어도 부분적으로 기초할 수 있다. 몇몇 경우에서, 미리 정의된 포인터 슬롯은 어떠한 참조 및/또는 할당 없이 초기화된다(예를 들면, 미리 정의된 포인터 슬롯은 "빈(empty)" 상태에서 초기화된다).

단계 2504는 제2 스크립팅 언어 객체를 스크립팅 언어 객체 내에 포함되는 미리 정의된 포인터 슬롯에 할당한다. 상기의 예에서, 스크립팅 언어 객체는 스크립팅 엔진 메모리 공간에 네이티브한 윈도우 객체를 포함하고, 한편, 미리 정의된 포인터 슬롯에 할당되는 제2 스크립팅 언어 객체는 윈도우 객체의 다큐먼트 특성 객체를 포함한다. 몇몇 실시형태에서, 미리 정의된 포인터 슬롯에 할당되는 제2 스크립팅 언어 객체는 스크립팅 엔진 메모리 공간 내에 존재한다.

단계 2506은 미리 정의된 포인터 슬롯에 할당되는 제2 스크립팅 언어 객체에 액세스한다. 이것은 임의의 적절한 방식으로 달성될 수 있다. 예를 들면, 몇몇 실시형태에서, 제2 스크립팅 언어 객체는 하나 이상의 액세서 함수를 통해 액세스될 수 있다. 상기에서 논의된 바와 같이, 스크립팅 엔진은 미리 정의된 포인터 슬롯에 의해 가리켜지게 되는 및/또는 미리 정의된 포인터 슬롯 내에 포함되는 객체에 액세스하도록 구성되는 액세서 함수를 제공하도록 구성될 수 있다. 몇몇 실시형태에서, 미리 정의된 포인터 슬롯에 할당되는 객체에 대한 액세스는, 상기에서 추가적으로 논의된 바와 같이, 스크립팅 엔진 메모리 공간 내에 그리고 레이아웃 엔진 메모리 공간 안으로 넘어가지 않으면서 포함된다.

미리 정의된 포인터 슬롯의 사용을 통해, 특성 객체와 관련되는 액세서는, 도메인 교차 통신을 사용하는 것으로부터, 동일한 메모리 공간(예를 들면, 스크립팅 엔진 메모리 공간) 내에 포함되는 통신을 단순히 사용하는 것으로 수정될 수 있다. 그러나, 이 대안적인 액세스를 사용함에 있어서의 하나의 고려사항은 보안 체크에 관한 것이다. 상기에서 논의된 바와 같이, 보안 체크는, 소정의 객체에 대한 액세서가 미리 정의된 타입의 객체에 의해서만 호출가능하다는 것을 강화하고/하거나 검증하는 것, 호출자의 도메인에 기초하여 객체 및/또는 액세서에 대한 액세스를 확인하고/하거나 강화하는 것 등과 같은 다양한 타입의 거동을 검증하고/하거나 확인하기 위해 사용될 수 있다. 액세서가 트램펄린 함수를 활용하는 앞서 설명된 예에서, 보안 체크는 트램펄린 함수 내에 내장될 수 있고/있거나 상주할 수 있다. 그러나, 미리 정의된 포인터 슬롯 액세스를 사용할 때, 트램펄린 함수는 더 이상 호출되지 않는데, 이것은 관련 보안 체크를 더 이상 호출하지 않는다. 몇몇 실시형태에서, 보안 체크는 스크립팅 엔진 메모리 공간에서 수행될 수 있다. 예를 들면, 미리 정의된 포인터 슬롯과 관련되는 액세서가 생성될 때 타입 정보는 스크립트 엔진으로 전달될 수 있다. 대안적으로 또는 추가적으로, 상기에서 추가로 설명되는 바와 같이, 타입 정보는 레이아웃 엔진에 의해 타입 초기화 동안 스크립팅 엔진으로 제공될 수 있다. 후속하여, 액세스가 호출될 때, 타입 정보는 호출하는 객체와 관련되는 타입 ID를 허용된 타입의 세트와 비교하여 호출이 허락되는 것을 보장하기 위해 사용될 수 있다. 따라서, 객체에 대한 허용된 그리고 허용되지 않은 액세스를 결정하기 위해, 스크립팅 엔진 메모리 공간에서 보안 체크가 수행될 수 있다.

상기에서 논의된 바와 같이, 확장 CustomExternalObject 상의 각각의 미리 정의된 포인터 슬롯은, 스크립팅 엔진 메모리 공간 내에서 설명되는 객체, 예컨대 특성 객체에 대한 포인터를 포함할 수 있다. 몇몇 실시형태에서, 이들 객체는, 상기에서 추가적으로 설명되는 바와 같이, 지연 초기화를 사용하여 구축될 수 있다. 다시 말하면, 특성이 처음 액세스될 때 객체가 생성된다. 그러나, 초기화 프로세스 동안, 미리 정의된 포인터 슬롯을 활용하는 특성 객체는, 임의의 관련 액세서 함수가 호출되기 이전에, 초기화되어 지정된 슬롯에 저장된다. 상기의 경우에서와 같이, 이것은 임의의 추가적인 메모리가 호출될 때까지 및/또는 활용될 때까지 참조되는 것을 방지한다.

스크립팅 엔진과 레이아웃 엔진 사이의 대안적인 액세스를 설명하였지만, 이제, 하나 이상의 실시형태에 따른 기타 고려사항의 다양한 양태의 논의를 고려한다.

기타 고려사항

하나 이상의 실시형태에 따르면, 레이아웃 엔진을 스크립팅 엔진과 바인딩하는 모델을 디자인함에 있어서, 기타 디자인 고려사항이 고려될 수 있다. 이제, 레이아웃 엔진 객체 및 스크립팅 언어 객체 통합 모델의 하기의 논의를 고려한다.

레이아웃 엔진 객체 및 스크립팅 언어 객체 통합 모델

하나 이상의 실시형태에서, 이중성 객체가 자신의 스크립팅 엔진 측과 자신의 레이아웃 엔진 측 사이에서 프로그램적으로 통합되도록 구성될 수 있다. 이중성 객체와 관련되는 스크립팅 언어 객체는, 대응하는 레이아웃 엔진 객체와 관련되는 추가적인 특성 및/또는 프로토타입뿐만 아니라, 다른 객체로부터 상속되는 특성 및/또는 프로토타입을 포함하기 위해, 자신의 디폴트 상태로부터 확장될 수 있다. 몇몇 실시형태에서, 레이아웃 엔진 객체의 API는, API가 스크립팅 언어에 네이티브한 방식으로 액세스될 수 있도록, 스크립팅 언어 객체의 룩업 경로에 포함될 수 있다. 하나 이상의 실시형태에서, API와 관련되는 프로토타입 객체는 생성되어 스크립팅 언어 객체에 어태치될 수 있다. 예를 들면, 레이아웃 엔진의 윈도우 객체와 관련되는 API는 프로토타입 객체와 관련되어 관련 스크립팅 언어 객체에 어태치될 수 있다. 마찬가지로, 웹 작업자의 글로벌 객체는, 레이아웃 엔진의 웹 작업자의 글로벌 객체와 관련되는 API를 포함하는 프로토타입을 어태치하는 것에 의해 확장될 수 있다. 이렇게 하여, 이중성 객체는 통합될 수 있고, 따라서 통합된 프로그래밍 액세스를 가능하게 한다.

몇몇 실시형태에서, 스크립팅 언어 객체로 및 스크립팅 언어 객체로부터 요청을 포워딩하기 위해 프록시가 구성될 수 있다. 예를 들면, 윈도우 프록시는 보안이 액세스를 허용할 때 스크립팅 언어 객체에 대한 호출을 중개하도록 구성될 수 있다. 때때로, 객체에 대한 직접 참조가 허용되지 않을 수 있다. 예를 들면, 이중성 객체, 기저의 레이아웃 엔진 객체에 대한 직접 참조는 금지될 수 있다. 이들 예에서, 직접 참조 대신 윈도우 프록시가 리턴될 수 있고, 따라서, 객체의 직접 노출 없이 기능성에 대한 액세스를 가능하게 한다.

레이아웃 엔진 객체와 스크립팅 언어 객체 사이의 객체 통합 모델을 설명하였지만, 이제, 하나 이상의 실시형태에 따르는 역호환성 지원(backwards compatibility support)의 논의를 고려한다.

역호환성 지원

하나 이상의 실시형태에서, 스크립팅 엔진에서 실행하는 스크립트는 상기에서 언급된 이중성 객체를 통해 레이아웃 엔진 객체에 액세스할 수 있다. 예를 들면, 스크립트는, 레이아웃 엔진 객체의 액세스를 획득하고/하거나 API를 호출하기 위해, 레이아웃 엔진 객체와 관련되는 var 객체에 액세스할 수 있다. 몇몇 경우에서, API를 호출하기 위해 대안적인 경로가 사용될 수 있다. COM 기반 모델을 활용하는 방식에서, ID를 직접적으로 획득하고/하거나 API를 호출하기 위해, COM 기반 클라이언트는 메소드, 예컨대 iUnknown 및/또는 iDispatch를 활용할 수 있다. 물론, 청구되는 주제의 범위를 벗어나지 않으면서, 다른 방식이 활용될 수 있다. 다른 경우에서, COM 기반 클라이언트는, 예컨대 iDispatchEx를 통해 더 많은 자동화된 액세스를 요청할 수 있는데, 이것은 당업자에 의해 인식될 것이다.

COM 기반 실시형태에서, COM 기반 클라이언트가 iUnknown 및/또는 iDispatch를 호출할 때, 그 호출은 레이아웃 엔진으로 포워딩될 수 있다. 레이아웃 엔진은 이들 호출을 동적으로 지원하도록 구성된다. 레이아웃 엔진은 COM 기반 클라이언트로 리턴할 티어 오프(tear-off) 객체 및/또는 인터페이스를 생성할 수 있다. 티어 오프 객체 또는 인터페이스는 요청된 기능성에 대한 동적 바인딩을 가능하게 한다.

하나 이상의 실시형태에서, COM 기반 클라이언트가 iDispatchEx를 호출하면, 그 호출은 스크립팅 엔진 주위로 포워딩될 수 있다. 몇몇 실시형태에서, 스크립팅 엔진과 스크립팅 엔진 객체 사이에 백채널이 생성될 수 있다. 백채널은 스크립팅 엔진과 스크립팅 엔진 객체 사이에서 사적 트랜잭션을 가능하게 하도록 구성될 수 있다. 예를 들면, 백채널을 통해, 스크립팅 엔진은, iDispatchEx를 보다 전통적인 방식으로 지원하기 위해 나타나는 동안, 스크립팅 엔진 객체의 기능성에 네이티브하게 액세스할 수 있다.

역호환성 지원을 설명하였지만, 이제, 하나 이상의 실시형태에 따른 다수의 스크립팅 엔진에 대한 지원의 논의를 고려한다.

다수의 스크립팅 엔진에 대한 지원

몇몇 실시형태에서, 제2 스크립팅 엔진은 제1 스크립팅 엔진의 확장을 통해 지원될 수 있다. 이중성 시스템에서, 제1 스크립팅 엔진은 이름 변환을 위해 내부적으로 먼저 검토하도록 구성될 수 있다. 이름 변환값이 스크립팅 엔진 룩업 프로세스에서 발견되지 않으면, 요청이 제2 스크립팅 엔진으로 라우팅될 수 있다. 제1 스크립팅 엔진은 제2 스크립팅 엔진으로부터의 메소드 호출을 지원하도록 확장될 수 있다.

기타 고려사항을 설명하였지만, 이제, 하나 이상의 실시형태에 따른 예시적인 시스템의 논의를 고려한다.

예시적인 시스템

도 26은 상기에서 설명된 다양한 실시형태를 구현하기 위해 사용될 수 있는 예시적인 컴퓨팅 디바이스(2600)를 예시한다. 컴퓨팅 디바이스(2600)는, 예를 들면, 도 1의 컴퓨팅 디바이스(102) 또는 임의의 다른 적절한 컴퓨팅 디바이스일 수 있다.

컴퓨팅 디바이스(2600)는 하나 이상의 프로세서 또는 프로세싱 유닛(2602), 하나 이상의 메모리 및/또는 스토리지 컴포넌트(2604), 하나 이상의 입/출력(input/output; I/O) 디바이스(2606), 및 다양한 컴포넌트 및 디바이스가 서로 통신하는 것을 허용하는 버스(2608)를 포함한다. 버스(2608)는, 메모리 버스 또는 메모리 컨트롤러, 주변장치 버스(peripheral bus), 가속 그래픽 포트, 및 다양한 버스 아키텍쳐 중 임의의 것을 사용하는 프로세서 또는 로컬 버스를 포함하는 임의의 여러 타입의 버스 구조 중 하나 이상을 나타낸다. 버스(2608)는 유선 및/또는 무선 버스를 포함할 수 있다.

메모리/스토리지 컴포넌트(2604)는 하나 이상의 컴퓨터 저장 매체를 나타낸다. 컴포넌트(2604)는 휘발성 매체(예컨대 랜덤 액세스 메모리(random access memory; RAM)) 및/또는 불휘발성 매체(예컨대 리드 온리 메모리(read only memory; ROM), 플래시 메모리, 광학 디스크, 자기 디스크 등)를 포함할 수도 있다. 컴포넌트(2604)는 고정식 매체(예를 들면, RAM, ROM, 고정식 하드 드라이브 등)뿐만 아니라 착탈식 매체(예를 들면, 플래시 메모리 드라이브, 착탈식 하드 드라이브, 광 디스크 등)를 포함할 수 있다.

하나 이상의 입/출력 디바이스(2606)는 유저가 커맨드 및 정보를 컴퓨팅 디바이스(2600)에 입력하는 것을 허용하고, 또한 정보가 유저 및/또는 다른 컴포넌트 또는 디바이스로 제시되는 것을 허용한다. 입력 디바이스의 예는 키보드, 커서 제어 디바이스(예를 들면, 마우스), 마이크, 스캐너 등을 포함한다. 출력 디바이스의 예는 디스플레이 디바이스(예를 들면, 모니터 또는 프로젝터), 스피커, 프린터, 네트워크 카드 등을 포함한다.

소프트웨어 또는 프로그램 모듈의 일반적인 맥락에서, 다양한 기술이 본원에서 설명될 수도 있다. 일반적으로, 소프트웨어는, 특정 태스크를 수행하는 또는 특정 추상 데이터 타입을 구현하는 루틴, 프로그램, 객체, 컴포넌트, 데이터 구조 등을 포함한다. 이들 모듈 및 기술의 구현예는 몇몇 형태의 컴퓨터 판독가능 매체 상에 저장되거나 또는 몇몇 형태의 컴퓨터 판독가능 매체를 통해 전송될 수도 있다. 컴퓨터 판독가능 매체는 컴퓨팅 디바이스에 의해 액세스될 수 있는 임의의 이용가능한 매체 또는 매체들일 수 있다. 비제한적인 예로서, 컴퓨터 판독가능 매체는 "컴퓨터 판독가능 저장 매체"를 포함할 수도 있다.

"컴퓨터 판독가능 저장 매체"는, 컴퓨터 판독 가능 명령어, 데이터 구조, 프로그램 모듈, 또는 다른 데이터와 같은 정보 저장을 위한 임의의 방법 또는 기술로 구현되는 휘발성 및 불휘발성의 착탈식 및 비착탈식의 매체를 포함한다. 컴퓨터 판독가능 저장 매체는, RAM, ROM, EEPROM, 플래시 메모리 또는 다른 메모리 기술, CD-ROM, 디지털 다기능 디스크들(digital versatile disk; DVD) 또는 다른 광학 스토리지, 자기 카세트들, 자기 테이프, 자기 디스크 스토리 또는 다른 자기 스토리지 디바이스, 또는 소망의 정보를 저장하기 위해 사용될 수도 있고 컴퓨터에 의해 액세스될 수 있는 임의의 다른 매체를 포함하지만, 이들에 제한되는 것은 아니다.

결론

다양한 실시형태는 웹 브라우저의 레이아웃 엔진과 스크립팅 엔진 사이에 인터페이스를 제공한다. 인터페이스는 레이아웃 엔진으로부터의 객체가 스크립팅 엔진의 메모리 매니저에 의해 인식되는 것, 및 능률적이고 효율적인 방식으로 상호작용하는 것을 가능하게 한다. 하나 이상의 실시형태에 따르면, 인터페이스는 브라우저 레이아웃 엔진 객체가, 스크립팅 엔진에 네이티브한 객체로서 생성되는 것을 허용한다. 대안적으로 또는 추가적으로, 몇몇 실시형태에서, 네이티브 객체는 또한, 레이아웃 엔진과 스크립팅 엔진 사이에서 기능성을 프록시하도록 구성된다.

몇몇 실시형태에서, 웹 브라우저의 레이아웃 엔진과 스크립팅 엔진 사이의 바인딩은, 레이아웃 엔진과 스크립팅 엔진 사이의 통합된 프로그래밍 액세스뿐만 아니라, 다수의 도메인에 걸친 보안 액세스를 가능하게 하도록 구성되는 피쳐를 포함할 수 있다. 그 피쳐는 메모리 관리를 향상시키고, 레이아웃 엔진과 스크립팅 엔진 사이의 직접 액세스를 가능하게 하고, 및/또는 이중성 객체의 가변성(mutability)을 가능하게 하도록 구성될 수 있다.

비록 본 주제가 구조적 피쳐 및/또는 방법론적 액트(act)에 고유한 언어로 설명되었지만, 첨부의 특허청구범위에서 정의되는 주제가 상기에서 설명되는 특정 피쳐 또는 액트로 반드시 제한되는 것은 아니다는 것이 이해되어야 한다. 오히려, 위에서 설명된 특정 피쳐 및 액트는 특허청구범위를 구현하는 예시적인 형태로서 설명된다.

Claims (19)

1. 컴퓨터 구현 방법에 있어서,
   레이아웃 엔진 메모리 공간에 적어도 하나의 레이아웃 엔진 객체를 생성하는 단계;
   스크립팅 엔진 메모리 공간에 제1 스크립팅 언어 객체 ― 상기 제1 스크립팅 언어 객체는 상기 적어도 하나의 레이아웃 엔진 객체에 링키지(linkage)를 통해 바인딩되며(bound), 상기 링키지는 상기 스크립팅 엔진 메모리 공간의 객체와 상기 레이아웃 엔진 메모리 공간의 객체 사이의 관계를 나타내도록 구성되는 커스텀 객체를 이용하고, 상기 커스텀 객체는 하나 이상의 포인터를 포함하고, 상기 하나 이상의 포인터 중 적어도 일부는 상기 스크립팅 엔진 메모리 공간 내의 다른 객체를 가리키도록(point) 구성됨 ― 를 생성하는 단계;
   상기 커스텀 객체와 관련되는 미리 정의된 포인터 슬롯에 제2 스크립팅 언어 객체와 관련되는 포인터를 할당(assign)하는 단계; 및
   상기 커스텀 객체와 관련되는 상기 미리 정의된 포인터 슬롯에 할당된 포인터를 사용해 상기 제2 스크립팅 언어 객체에 액세스하는 단계
   를 포함하는, 컴퓨터 구현 방법.
2. 제1항에 있어서,
   상기 제2 스크립팅 언어 객체에 액세스하는 단계는, 상기 레이아웃 엔진 메모리 공간 내로 넘어가지 않으면서 그리고 상기 스크립팅 엔진 메모리 공간으로부터, 상기 제2 스크립팅 언어 객체에 액세스하는 단계를 더 포함하는 것인, 컴퓨터 구현 방법.
3. 제2항에 있어서,
   상기 제2 스크립팅 언어 객체에 액세스하는 단계는, 하나 이상의 액세서 함수(accessor function)를 사용하여 상기 제2 스크립팅 언어 객체에 액세스하는 단계를 더 포함하는 것인, 컴퓨터 구현 방법.
4. 제1항에 있어서,
   상기 제2 스크립팅 언어 객체에 액세스하는 단계는, 상기 제1 스크립팅 언어 객체와 관련되는 특성 객체로서 상기 제2 스크립팅 언어 객체에 액세스하는 단계를 더 포함하는 것인, 컴퓨터 구현 방법.
5. 제4항에 있어서,
   상기 제1 스크립팅 언어 객체는 윈도우 객체를 포함하는 것인, 컴퓨터 구현 방법.
6. 제1항에 있어서,
   상기 제2 스크립팅 언어 객체에 액세스하는 단계는, 상기 제2 스크립팅 언어 객체에 대한 액세스가 허용된다는 것을 결정하는데 유효한 하나 이상의 보안 체크를 수행하는 단계를 더 포함하는 것인, 컴퓨터 구현 방법.
7. 제6항에 있어서,
   상기 하나 이상의 보안 체크 중 적어도 하나의 보안 체크는, 호출하는 객체(calling object)와 관련되는 타입 정보(type information)를 상기 제2 스크립팅 언어 객체에 대한 액세스와 관련되는 허용된 타입과 비교하는 단계를 포함하는 것인, 컴퓨터 구현 방법.
8. 하나 이상의 컴퓨터 실행가능 명령어를 저장한 컴퓨터 판독가능 하드웨어 저장 메모리에 있어서,
   상기 하나 이상의 컴퓨터 실행가능 명령어는, 적어도 하나의 프로세서에 의한 실행에 응답하여, 웹 브라우저의 레이아웃 엔진과 관련 스크립팅 엔진 사이의 하나 이상의 바인딩을 가능하게 하는 하나 이상의 인터페이스 정의 언어(Interface Definition Language; IDL) 파일 및 하나 이상의 특성 설명 언어(Property Description Language; PDL) 파일이 생성되게 하도록 구성되고,
   상기 하나 이상의 PDL 파일은 하나 이상의 스크립팅 언어 객체를 설명하도록 구성되고,
   상기 하나 이상의 IDL 파일은 상기 웹 브라우저의 레이아웃 엔진과 관련 스크립팅 엔진 사이의 하나 이상의 바인딩과 관련되는 하나 이상의 속성을 포함하도록 구성되고,
   상기 하나 이상의 속성 중 적어도 하나의 속성은, 상기 하나 이상의 스크립팅 언어 객체 중의 한 스크립팅 언어 객체와 관련되는 커스텀 객체 내에 확보하여 포함시킬, 일정 개수의 미리 정의된 포인터 슬롯에 주석을 달도록 구성되고,
   상기 커스텀 객체는 하나 이상의 포인터를 포함하며, 상기 하나 이상의 포인터 중 적어도 일부는 상기 관련 스크립팅 엔진과 관련되는 스크립팅 엔진 메모리 공간 내의 다른 객체를 가리키도록 구성되고,
   상기 하나 이상의 속성 중 적어도 하나의 속성은, 상기 하나 이상의 스크립팅 언어 객체 중의 한 스크립팅 언어 객체에 대한 허용가능한 액세스를 결정하는 것과 관련되는 정보에 주석을 달도록 구성되는, 컴퓨터 판독가능 하드웨어 저장 메모리.
9. 제8항에 있어서,
   하나 이상의 속성 중 상기 적어도 하나의 속성은 또한, 하나 이상의 스크립팅 언어 객체 중의 상기 스크립팅 언어 객체와 관련되는 계층(hierarchy)에 적어도 부분적으로 기초하여, 확보할 상기 일정 개수의 미리 정의된 포인터 슬롯에 주석을 달도록 구성되는, 컴퓨터 판독가능 하드웨어 저장 메모리.
10. 제8항에 있어서,
    상기 하나 이상의 속성 중 적어도 하나의 속성은, 상기 커스텀 객체 내에 포함되는 미리 정의된 포인터 슬롯과 관련시킬, 상기 하나 이상의 스크립팅 언어 객체 중의 한 스크립팅 언어 객체를 식별하도록 구성되는, 컴퓨터 판독가능 하드웨어 저장 메모리.
11. 제10항에 있어서,
    상기 하나 이상의 컴퓨터 실행가능 명령어는 또한, 상기 커스텀 객체 내에 포함되는 미리 정의된 포인터 슬롯과 관련되는 하나 이상의 스크립팅 언어 객체 중의 상기 스크립팅 언어 객체의 지연된 초기화(deferred initialization)를 가능하게 하도록 구성되고, 상기 지연된 초기화는 하나 이상의 스크립팅 언어 객체 중의 상기 스크립팅 언어 객체가 액세스될 때에 하나 이상의 스크립팅 언어 객체 중의 상기 스크립팅 언어 객체를 초기화하는 것을 포함하는, 컴퓨터 판독가능 하드웨어 저장 메모리.
12. 제10항에 있어서,
    상기 하나 이상의 바인딩은, 상기 커스텀 객체 내에 포함되는 미리 정의된 포인터 슬롯과 관련되는 하나 이상의 스크립팅 언어 객체 중의 상기 스크립팅 언어 객체와 관련되는 하나 이상의 액세서 함수를 더 포함하고, 상기 하나 이상의 액세서 함수는, 상기 웹 브라우저의 레이아웃 엔진과 관련된 레이아웃 엔진 메모리 공간 내로 넘어가지 않으면서, 상기 관련 스크립팅 엔진과 관련되는 스크립팅 엔진 메모리 공간에서 기능성을 호출하도록 구성되는, 컴퓨터 판독가능 하드웨어 저장 메모리.
13. 시스템에 있어서,
    적어도 하나의 프로세서; 및
    하나 이상의 컴퓨터 실행가능 명령어를 저장한 하나 이상의 컴퓨터 판독가능 하드웨어 저장 메모리
    를 포함하고, 상기 하나 이상의 컴퓨터 실행가능 명령어는 상기 적어도 하나의 프로세서에 의한 실행에 응답하여,
    레이아웃 엔진 메모리 공간에 적어도 하나의 레이아웃 엔진 객체를 생성하고;
    스크립팅 엔진 메모리 공간에 제1 스크립팅 언어 객체 ― 상기 제1 스크립팅 언어 객체는 상기 적어도 하나의 레이아웃 엔진 객체에 링키지를 통해 바인딩되며, 상기 링키지는 상기 스크립팅 엔진 메모리 공간의 객체와 상기 레이아웃 엔진 메모리 공간의 객체 사이의 관계를 나타내도록 구성되는 커스텀 객체를 이용하고, 상기 커스텀 객체는 하나 이상의 포인터를 포함하고, 상기 하나 이상의 포인터 중 적어도 일부는 상기 스크립팅 엔진 메모리 공간 내의 다른 객체를 가리키도록 구성됨 ― 를 생성하고;
    상기 커스텀 객체와 관련되는 미리 정의된 포인터 슬롯에 제2 스크립팅 언어 객체 ― 상기 제2 스크립팅 언어 객체는 상기 적어도 하나의 레이아웃 언어 객체와 관련되는 특성 객체를 포함함 ― 와 관련되는 포인트를 할당하고;
    상기 스크립팅 엔진 메모리 공간 내에 머무르면서, 상기 특성 객체와 관련되는 액세서 함수를 이용하여, 상기 커스텀 객체와 관련되는 미리 정의된 포인터 슬롯에 할당되는 포인터를 사용해 상기 제2 스크립팅 언어 객체에 액세스하도록 구성되는, 시스템.
14. 제13항에 있어서,
    상기 액세서 함수는 상기 스크립팅 엔진 메모리 공간 내에 설명되는 게터(getter) 액세서 함수를 포함하는, 시스템.
15. 제13항에 있어서,
    상기 제2 스크립팅 언어 객체에 액세스하기 위한 하나 이상의 컴퓨터 실행가능 명령어는 또한, 윈도우 객체와 관련되는 특성 객체로서 상기 제2 스크립팅 언어 객체에 액세스하도록 구성되는 것인, 시스템.
16. 제15항에 있어서,
    상기 제2 스크립팅 언어 객체는 다큐먼트 객체를 포함하는 것인, 시스템.
17. 제13항에 있어서,
    상기 제2 스크립팅 언어 객체에 액세스하기 위한 하나 이상의 컴퓨터 실행가능 명령어는 또한, 상기 스크립팅 엔진 메모리 공간에 있어서, 상기 제2 스크립팅 언어 객체에 대한 액세스가 허용된다는 것을 결정하는데 유효한 적어도 하나의 보안 체크를 수행하도록 구성되는 것인, 시스템.
18. 제17항에 있어서,
    상기 하나 이상의 컴퓨터 실행가능 명령어는 또한, 상기 스크립팅 엔진 메모리 공간에 있어서, 상기 제2 스크립팅 언어 객체에 대한 액세스가 허용되지 않는다는 것을 결정하도록 구성되는 것인, 시스템.
19. 제13항에 있어서,
    상기 하나 이상의 컴퓨터 실행가능 명령어는 또한, 상기 액세스에 응답하여 상기 제2 스크립팅 언어 객체를 초기화하도록 구성되는 것인, 시스템.

Images