BONDI Feature Access
Features의 인식과 구성에 관한것과 웹애플리케이션에서 그 정보에 어떻게 억세스하는지에 대한 요구사항에 대해 설명한다.
요구사항 요약과 원리
BONDI Web app의 의존성은 하나 이상의 features의 구성에 의해 결정된다.
하나의 Feature는 웹런타임에서 제공하는 연관된 기능에 대응된다. 이는 자바스크립트 인터페이스와 웹런타임의 동작에 대한 집합으로 정의된다.
하나의 feature는 유일한 IRI로 구분되며 BONDI web app에 의해서 의존성을 표현하는 하나의 유닛이다.
BONDI는 하나의 feature를 정의하거나 몇개의 feature를 정의하기도 한다. 각각은 인터페이스를 정의한다. BONDI framework에서 JavaScript API를 확장하고 싶다면 대응되는 feature를 반드시 정의해야 한다. JavaScript API와 feature를 추가하였다면 feature-set도 또한 정의해야 한다. IRI로 구분이 되며 feature들의 집합이다.
framework과 연관된 요구사항들은 아래의 원칙들로 규합된다.
1. Feature 추가 : JavaScript API의 집합은 고정되어 있지 않다. 그리고 나중에 확장되기를 기대하고 있다.
2. Feature 혁신 : 각 JavaScript API들은 스스로 시간이 지남에 따라 진화한다. 새로운 디바이스의 능력을 반영하기도 하고 새로운 유스케이스 또는 에러 수정, 이전 버전의 JavaScript의 결점을 보완하는것등을 통해서 진화한다.
3. feature 정의의 분산 : feature의 정의는 어느 집단에 의해 제한되지 않는다. 누구나 정의가능하다(다만 다른디바이스와 호환은 포기). feature의 정의는 단말생산자, 네트워운영자, 특별히 관심있는자, 각 서비스제공자나 퍼블리셔들에 의해 정의가능하다.
프레임웍은 또한 동적으로 feature를 제공하기 위한 방안을 고려하여 설계 되었다.
4. 동적 feature 제공 : 확장메커니즘을 통해서 필드에 존재하는 디바이스에 새로운 feature를 추가할 수 있는 기능. 이 기능은 일반적으로 디바이스 플래싱을 다시하는 방법이 아니다. 확장메커니즘은 OS에서 제공가능한 방법이 되며 ActiveX나 브라우져의 플러그인등이 그방법이 될수 있다. 하지만 이 메커니즘은 반드시 제공되어야 하는 것은 아니며 feature 제공을 위해 표준화가 완전히 이루어진것도 아니다.
이런 원리가 의미하는것은 아래에 설명된다.
5. Feature들(interface와 구현을 포함하는)는 IRI로 구분이 가능하다.
6. 모든 Web App(website or widget)은 feature를 사용하기 위해 반드시 feature를 정의해야 한다. 이 정보는 Widget Recource의 Widget Configuration Document에 선언되어 있거나 또는 BONDI-defined API를 이용하여 프로그램으로 선언한수도 있다.
이 선언은 다음을 허용한다.
- 웹런타임이 그 feature를 제공하는지 확인한다.
- feature의 동적 제공을 허용한다.
- 웹어플리케이션이 그 feature를 사용할 수 있는지 확인하는 억세스컨트롤을 허용한다.
- 웹런타임이 어떤 feature를 로드하고 바인드해야 하는지 결정하는데 필요.
- Widget User Agent가 위젯을 설치하기 전에 웹런타임에서 동작가능한 위젯인지 결정하는데 필요.
BONDI는 자체적으로 두종류의 feature를 정의한다.
1. BONDI JavaScript APIs : 이 feature는 BONDI-defined API와 직접적으로 연관된다. http://bondi.omtp.org/api/로부터 정의되어진다.
2. BONDI processing assertions : metadata와 assertions그리고 웹어플리케이션을 처리하기 위해 관련된 다른 directive들로 구성된다. http://bondi.omtp.org/meta/로부터 정의되어 진다.
위젯을 위해서 BONDI는 Widget Configuration Document에서 <feature> 태그로 위젯의 feature의존성을 기술할 수 있다.
의존성의 표현
BONDI는 다음 4가지를 정의한다.
1. Device Capability
2. JavaScript API
3. Feature
4. Feature Set
WebApplicaiton은 feature 의존성을 반드시 명시적으로 기술해야 한다. 웹런타임은 해당 feature가 명시적으로 요구되지 않은 상태에서는 유효한 feature가 없고 Security Policy에 의해 허용되면 접근가능지는 것을 보장해야 한다.
활성화된 접근성은 허용된 Web Application에 대해서만 유효하다.
요구사항
AS-0351 : 웹런타임은 반드시 명시적으로 연관된 feature를 기술하고 그 권한을 획득한 경우에만 JavaScript API를 사용할수 있게 해주어야 한다.
AS-0552 : 이미 유효한 feature가 있는지 결정할 수 있어야 함.
…
의존성의 정적 선언
Widget Configuration Document에 <widget> tag의 <feature> tag에 name과 required 속성으로 기술한다.
ex)
<widget xmlns="http://www.w3.org/ns/widgets" version="5602:5719M"id="http://tests.bondi.omtp.org/widgets/appconfig.wgt" width="640" height="480">
<name>BONDI appconfig compliance</name>
<author email="hendry@aplix.co.jp">Kai Hendry</author>
<feature name="http://bondi.omtp.org/api/bondi.requestfeature" />
</widget>
BONDI-defined API인 requestFeature를 통해서 표현 가능하다.
PendingOperation requestFeature(
in RequestFeatureSuccessCallback successCallback,
in ErrorCallback errorCallback,
in DOMString name);
이 함수는 명명된 feature를 비동기로 요청을 하며 리턴값으로 pending operation object를 받는다. 성공하면 successCallback이 호출되며 실패하면 errorCallback에 DeviceAPIError가 발생한다.
요청된 feature와 연관된 JavaScript API가 존재하면 모든 API들의 global property들이 successCallback이 호출되기 전에 접근가능해진다. 보통 해당 API set의 root object를 생성하며 생성이 성공하면 successCallback에 인자로 넘겨진다.
