위젯이란?

06/04/2010

위젯이란 용어가 여기저기 사용하면서 부터, 실제로 W3C/BONDI/JIL, 나아가 WAC에서 말하는 위젯에 대해서 정리가 필요한 것 같아서 아래와 같이 적어보았습니다.

우선 제가 예전에 정리해둔 자료입니다. (해당 Spec의 내용을 그대로 옮겨온 것 입니다.)

*BONDI

A Widget is understood to be an interactive single purpose application for displaying and/or updating local data or data on the Web, packaged in a way to allow a single download and Installation on a user’s machine, mobile phone, or mobile Internet Terminal

Web Application

An Application authored using web formats that makes use of Scriptable APIs, e.g. an installed Widget, web based Application or hybrid.

*JIL

A JIL Widget is a composition of HTML, JavaScript, and CSS combined as a package that can be deployed on a JIL compatible mobile handset. The widget package is self-contained; the package includes all of the support files that are needed by the widget. With this approach, the widget can become a standalone application that does not require any external resources. Any external access issues in running a widget can be safely handled or even avoided.

*W3C http://www.w3.org/TR/widgets/

Widgets are full-fledged client-side applications that are authored using Web standards and packaged for distribution. They are typically downloaded and installed on a client machine or device where they run as stand-alone applications, but they can also be embedded into Web pages and run in a Web browser. Examples range from simple clocks, stock tickers, news casters, games and weather forecasters, to complex applications that pull data from multiple sources to be “mashed-up” and presented to a user in some interesting and useful way (see [Widgets-Landscape] for more information).

*W3C http://www.w3.org/TR/widgets-land/

A widget is an end-user’s conceptualization of an interactive single purpose application for displaying and/or updating local data or data on the Web, packaged in a way to allow a single download and installation on a user’s machine or mobile device. A widget may run as a stand alone application (meaning it can run outside of a Web browser), or may be embedded into a Web document. In this document, the runtime environment on which a widget is run is referred to as a widget user agent and a running widget is referred to as an instantiated widget. Prior to instantiation, a widget exists as a widget resource.

그리고, BONDI_Architecture_and_Security_v1.1 나오는 내용입니다.

Web ApplicationThe term used generically to refer to an application delivered using web technology, whether as a Website or a Widget.

WidgetAn interactive application for displaying and/or updating local data or data on the Web, packaged in a way to allow a single download and installation on a user’s machine or mobile device.

끝으로, 보시는 바와 같이 Web Application 이 Widget을 포괄하는 것을 확인할 수 있습니다.


BONDI 2nd TestFest 를 다녀와서

05/25/2010

Windsor !

저번에는 런던 센터였지만, 이번에는 서쪽으로 좀 떨어진 윈저에서 같은 회사 Test Leader 이신 Chris님과 함께 BONDI TestFest를 아래와 같이 3일간  진행하였습니다. (추가 2일은 WAC 미팅)

Day 1

그 동안 메일로 오고간 정황상, BONDI 1.11을 위한 RI는 어느정도 완료되었고, 따라서 그에 따른 Test 만 잘 수행할 수 있다면 된다고 생각했었다.

하지만 역시, 그렇지는 않았다. 설상가상으로 오전 11시까지는 인터넷(WiFi) 설정도 안되었으니 말이다.

이 번 TestFest의 소개와 업무 분담을 하고 나니, 바로 점심을 먹으러 갈정도로 오전은 진척이 없었다. (우리나라에서는 있을 수 없는 일이지만, 역시나 다들 여유가 넘쳤다. 항상 !!)

오후에는 contact module 의 test framework 중에서 버그가 몇 개 있어서 수정하였고, 금방 5시가 되었다.

옆방에는 저번 Seattle 미팅이 취소되는 바람에 Conference Call에서 결정하지 못 한 사항들에 대해서 논의되는 자리가 있었는데, 저녁에는 모두 같이 모여서 식사와 음료(?)를 하였다.

Day 2

contact module에 대해서 어느정도 완료하고, 추가적으로 messaging module 쪽을 보기로 하였다.

역시 코딩/디버깅을 하니 시간이 너무 너무 잘 갔다.

결과는 test framework 자체보다는 RI가 구현이 덜 되어서(혹은 WebVM의 한계) , 우리가 할 수 있는 것이 그리 많지는 않았다.

다음 날이 TestFest의 마지막 날이라(실제적으로는 OMTP BONDI TestFest의 마지막), 우리는 좀더 잘 하기 위해서 호텔에 와서도 일부 업무를 계속 진행하였다.

Day 3

TestFest 마지막 날…

마지막 날이라 뭔가 좀더 아웃풋을 내기 위해서 오전부터 집중해서 달렸는데, emulator 나 device 모두 crash가 계속 되는 바람에 삽질의 연속이었다.

이는 비단 우리뿐만이 아니었다. Messaging은 정말 최악의 선택이었다 ㅠㅠ.

Messaging 을 포함하여 다른 모듈은 계속 f/up을 하기로 하고, 적당한 선에서 (적당한 이유와 함께) TestFest를 종료하였다.

어쨌든, BONDI 1.11 spec은 곧 나올 것이며,  비록 Test Framework이 완벽하지 않더라도 이해해 주시길… WinMo 자체의 문제도 있고^^.

그럼 여기까지 하고 다음에 또 뵙겠습니다.

p.s) 좀 더 자세한 얘기와 특히 WAC 관련은 여기서 다룰 수 없어서 아쉽네요. (회사 보안상의 이유로 ㅠㅠ)

바라건대, 7월부터는 wackorea 로 찾아뵐 수 있을지 모르겠습니다.^^


How to build the BONDI RI(Reference Implementation).

04/09/2010

지난 bondi RI 에서는 bondi에서 배포하는 버전을 설치하고 실행하는 부분에 대해서 다루었습니다.

이번에는 bondi RI의 소스를 build 해서 실행하는 방법에 대해서 알아보겠습니다.

1. windows mobile 개발 환경 구성

bondi RI는 windows mobile 환경에서 설치 및 실행되므로 아래 개발 환경이 우선 설치 되어야 합니다.

- visual studio 2005 Professional or Team system editions

- windows mobile 6 professional SDK

visual studio 2005에서는 professtional 이상의 버전을 사용해서 windows mobile 개발이 가능합니다. 이 버전 이상이 설치 되어있다면 windows mobile 6 professional SDK를 mircosoft site에서 다운로드 받아 설치합니다. (다운로드 바로 가기)

2. bondi RI source

개발 환경이 구축되면 이제 bondi RI 소스와 bondi RI의 구동에 필요한 webvm SDK를 설치합니다.

omtp에서는bondi RI의 소스를 svn으로 관리를 하므로 svn에 필요한 client 프로그램을 설치하면 아래 주소에서 받을 수 있습니다. 필자는 윈도우용 svn client인 tortoisesvn 를 이용했습니다.

http://svn.omtp.org:8080/svn/bondi/trunk

현재 svn에는 인증을 필요로 합니다.  bondi development site에 회원가입을 하고 가입 확인 메일을 받으면 가입한 ID/PW로 인증이 가능합니다.

3. webvm SDK

webvm은 browser에서 PIM, Geolocation 등의 native feature를 사용하기 일종의 plug-in 입니다. bondi APIs에서는 다양한 종류의 native featrue를 사용하므로 browser에서 이 부분을 연결하기 위해서 bondi RI(windows mobile)에서는 webvm을 이용합니다.  그러므로 bondi RI를 build 하기 위해서는 webvm SDK가 필요합니다.

webvm에 대한 상세 내용은 http://webvm.net/ 를 참고하십시오.

그럼 이제 build 필요한 마지막 부분인 webvm SDK를 설치해야 합니다.  http://sdk.webvm.net/에서 이름, 메일 정보등을 입력하고면 메일로 다운로드 가능한 주소를 보내줍니다. ( 테스트용으로 받기위해서 요청을 했을 때 답변 메일에 3시간 정도가 소요되었습니다.)

다운로드 SDK의 압축을 풉니다. 그리고 아래의 경로를 windows 경로에 추가합니다.

WEBVMHOME=C:\path\to\your\webvm-sdk

이 경로의 include/webvm.h 파일을 이용하기 위한 내용이므로 꼭 추가해 주어야 합니다.

4. build

모든 환경이 준비 되었으면 visual studio 로  {bondi RI source path}\ri\build\wince\build.sln 프로젝트를 load하고 target을 Windows Mobile 6 Professional SDK (ARMV4I) 로 설정한 다음 build를 실행합니다.

bondi RI는 지속적인 수정이 되고 있는 상태이기 때문에 build 에 대해서 관리가 되지 않아서 무수한 에러와 만나게 될지도 모릅니다. 그럼에도 build 해서 실제 실행되는 부분을 확인하기 위해서는 에러를 직접 해결해야 합니다. : p

2010.04.01 기준의 소스를 받았을 때 발생한 에러에 대해서는 아래 내용을 적용하면 정상적으로 build가 되니 참고하십시오.

- fixed build error

  • C:\Program Files\Microsoft Visual Studio 8\VC\ce\include\comdef.h (240 line) 을 수정.  int nLen = ::lstrlen(m_pszMsg);   부분을 다음으로 변경   int nLen = lstrlen(m_pszMsg);
  • C:\path\to\your\webvm-sdk\include\webvm.h 파일을 {bondi RI source path}\ri\module\common\webvm.h 파일로 교체
  • MessagingCommon project 를 삭제하고 {bondi RI source path}\ri\module\common\messagingCommon2\wince\messagingCommon.vcproj 를 새로운 project로 Add. 추가로 WCommsLog project properties -> input lib에서 messsagingCommon을 messagingCommon2로 변경.
  • bondi_FeatureCallback_decl.h 를 include 한 부분 주석 처리

2010.04.01 소스는 위에 부분의 수정으로 build가 가능합니다.

5. Run bondi RI

이상 없이 build 가 완료되면 {bondi RI source path}\ri\build\wince\bin\ 아래에 BondiSetup1-016d.cap 파일이 생성됩니다. 이 설치 파일을 windows mobile emulator에서 설치하면 정상적으로 bondi RI가 실행되는 것을 확인할 수 있습니다.

참고로 아래 부분을 수정하면 debug mode로 emulator에서 실행도 가능합니다. (마찬가지로 2010.04.01 소스 기준으로 추후에 다르게 변경 될 수 있습니다.)

  • userAgent project를 Set as Startup project로 선택
  • package project properties -> Deployment -> Register Output No로 변경
  • userAgent project properties -> Deployment -> Remote Directory를 %CSIDL_PROGRAM_FILES%\bondi 로 변경

6. conclusion

bondi 에서 배포하는 RI source는 계속적인 수정과 버전 관리 process의 부재로  build & run 에는 아직 여러가지 문제들이 있습니다. 그렇지만 bondi APIs 의 내부적인 동작에 대해서 관심이 있다면 현재 참고할 수 있는 유일한 reference입니다.


7th testfest를 다녀와서

03/15/2010

지난 주 런던에서 열렸던 testfest에 대한 얘기를 해볼까 합니다.
원래는 codefest였지만, 성격상 testfest가 맞았습니다.

Compliance 그룹(of BONDI) 의 의장이신 리스께서 아래와 같은 Agenda로 미팅을 주관해 주셨습니다.

  • Testfest에 대한 소개 및 목적
  • BONDI Test Framework 소개 및 Test 작성방법
  • 그리고, Test 작성하는 간단한 샘플
  • 둘째날 부터는 계속 test code를 넣고, 서로 리뷰를 하였습니다.

날짜별로 좀 더 자세히 얘기하자면 아래와 같다.
(일련의 모든 사항을 적기보다는 느낌을 중심으로 작성했습니다.)

Day 1

먼저 리스가 의장이 된 이유를 (아무도 나서는 이가 없어서 어쩔 수 없이 이렇게 되었다고 말함) 꺼내면서 미팅이 시작되었다. (60정도 되어보이는 백발 개발자의 겸손함과 지혜를 엿볼 수 있었음.)

그리고, Test code가 실제 BONDI 페이지에 연결된 svn에 바로 commit 되는 것이라 놀라지 않을 수 가 없었다. WebVM 담당자인 카이(Kai) 말로는 실제로 어떤 이가 파일 자체를 날려서, 일일이 복구하는 일도 생겼었다고-_-;

참가한 사람이 그렇게 많지 않아서(10명정도), 2~3명이 한팀이 되어서 주요 모듈을 맡아서 Test 작성이 시작이 되었다. 물론 나랑 같이 간 Denny와 같은 팀이였으며, 우리가 맡은 모듈은 Contact 이었다. (사실 이 때까지만 해도 BONDI test framework 에 대한 동작방식은 이해할 필요가 없어서, 깊이 있게 보지는 않았었다. 바로 이게 우리가 좀더 잘 할 수 있었는데 부족했던 부분이 아닌가 한다.)

Day 2

우리는 스펙의 문장 하나하나를 면밀히 분석하여, assertion 들을 리스트업 하였다.  예를들어 If any argument is wrong the ErrorCallback will be invoked with a DeviceAPIError INVALID_ARGUMENT_ERROR 이 있으면, 실제로 인자가 잘 못 들어갔을 경우 ErrorCallBack을 리턴하는 지와 그때 Error 코드가  INVALID_ARGUMENT_ERROR 인지를 체크해야한다.

실제 Contact의 경우에는 다른 모듈에 비해서 작업이 너무나 안되어 있었다. 그래서 우리는 대부분의 코드를 처음부터 다시 작성해야 했으며, 많은 삽질을 하는 계기가 되었다. ㅠㅠ.

또한 우리는 Browser based 뿐 아니라 Widget에 대해서도 돌아갈 수 있도록 호텔에 와서도 열심히 삽질을 하였다. (RI가 너무 구현이 안되어있어서, 실제로 테스트 해볼 수 있는 것은 거의 없었다.)

Day 3

계속되는 코딩… (중략)

그러나, 이 날은 저녁에 한국 식당에 가서 소주한잔을 할 수 있는 여유가 있었다. 사실 한국에 1년간 산 적이 있는 카이가 가자고 제안했으며, 브라이언도 기꺼이 동행해서 4명이서 즐거운 저녁시간을 보냈다.

Day 4

… (중략) 마치며,

If no filter is passed all the contacts will be returned 의 경우 실제로 제대로 돌아가는 지 확인할 Test assertion을 찾을 수 가 없었다.

혹, 관심있는 분은 어떻게 하면 이 것을 검증할 수 있는지 생각해보길 바랍니다.

p.s) 제가 다니는 회사와 관련된 정보나 아직 확정되지 않은 것에 대해서는 일부러 언급하지 않았습니다.
그리고, 다음 Codefest는 7월에 열릴 예정인데, 그때는 좀더 나은 모습을 보일 수 있도록 미리 노력을 많이 하도록 하겠습니다.


Device API Access Control – attribute of subject element

03/10/2010

1. Introduction

이번에는  device API에 접근을 위해 접근을 요청한 widget이 API에
접근이 가능한 widget인지를 확인에 이용되는 subject element와
attribute 에 대해서 알아보도록 하겠습니다.

이 subject element 는 API에 접근이 가능한 widget 혹은 접근이
불가능한 widget을 구분하여 API에 접근하는 것을 제어할 수
있습니다. 일반 휴대전화에도 있는 white list/black list 라고
생각하면 더 이해하기 쉬울 것 같습니다.

그럼 이제부터 subject element 에 대해서 알아보도록 하겠습니다.

2. Subject element

이 subject element 는 BONDI에서 정의한 XML format 에 포함되는
element 로 widget 하나 혹은 여러 widget을 묶음으로 관리하기 위한
element 입니다.  이 element 는 subject-match라는 child element 를
가지고 있고, subject-match에 widget을 분류하는 attribute 들이
있습니다. 그럼 widget을 분류 하기위한 attribute가 어떠한 것이
있는지 알아보도록 하겠습니다.

ATTRIBUTE TYPE VALUE
class String 요청을 한 App이 widget 인지 website 인지 구분
install-uri  URI  해당 widget을 설치한 URI
id  URI  config.xml 에 정의 되어 잇는 widget id
version  string  widget 의 version
distributor-key-cn  string  widget 공급자 서명을 위한 인증서의 common name
distributor-key -fingerprint string  widget 공급자 서명을 위한 인증서의 지문정보
distributor-key-root-cn  string  widget 공급자 서명을 위한 root 인증서의 common name
distributor-key-root-fingerprint  string  widget 공급자 서명을 위한 root 인증서의 지문정보
author-key-cn  string  widget 저자 서명을 위한 인증서의 common name
author-key -fingerprint  string  widget 저자 서명을 위한 인증서의 지문정보
author-key-root-cn  string  widget 저자 서명을 위한 root 인증서의 common name
author-key-root-fingerprint string widget 저자 서명을 위한 root 인증서의 지문정보
widget-attr:name   config.xml 에 정의 되어 잇는 widget name

 위의 표와 같이 여러가지의 attribute 들이 정의 되어 있습니다.
각 subject-match는 위의 attribute 를 하나씩 포함을 하고 있으며
여러개의 subject-match를 포함하고 있는 subject element 는
포함된 subject-match의 value 가 모두 TRUE 이어야만
subject 가 TRUE가 됩니다.

이렇게 하여 사업자, 제조사 그리고 사용자가 원하는 widget에게
필요한 만큼만 resource 를 open 함으로 악의적의 공격으로 부터
device 를 보호할 수 있게 됩니다.

3. Opinion

이번에는 subject에 관련된 것들을 알아보았습니다. 이 보안은
몇 번을 강조해도 지나치지 않다고 생각하는데요. 특히, widget
website에서도 device 의 resource 에 접근이 가능해지면서
보안은 더 중요시 되고 있는 것 같습니다. PC에도 중요한 정보가
많이 있겠지만 mobile device 의 경우는 많은 사람의 연락처 등
PC 못지 않게 혹은 PC보다 더 중요하고 많은 개인정보를 담고
있습니다. 보안 관련 솔루션을 개발하는 개발자들이 아무리
잘만들더라도 개인이 소홀이 할 경우 중요한 개인 정보는
해커들의 손에 넘어가게 되어 있습니다. 언제나 보안을 신경쓰는
습관을 들이는 것이 최고의 보안이 아닐까 생각합니다.
그럼 다음에 또 뵙겠습니다.

Reference

http://bondi.omtp.org/1.1/security/BONDI_Architecture_and_Security_Appendices_v1.1.pdf


The 7th BONDI Codefest

02/26/2010

원문 : http://blog.omtpbondi.org/2010/02/next-bondi-codefest-event-announced-in-london.html

오는 3월 8일부터 11일까지 런던 OMTP 사무실에서, BONDI Codefest가 열립니다.

Codefest 이벤트는 BONDI RI (레퍼런스 구현)가 BONDI 스펙에 따라 얼마나 잘 개발되었는지와 BONDI 스펙이 얼마나 잘 구현되었는지(실용성)를 동시에 확인할 수 있습니다.  또한 BONDI 스펙을 이용해서 새로운 위젯도 만들어서, 서로 가치를 나누는 자리이기도 합니다.

아직 자세한 일정은 나오지 않은 상태지만, 오가는 메일 내용을 볼 때 test 및 compliance가 주내용이라고 합니다. 보다 궁금하신 사항이 있으면, 댓글이나 메일 주시구요.

실제 진행되는 내용은 Codefest 참석 후, 후기를 올리도록 하겠습니다.
첫 Codefest이지만, 다행히 동료와 함께 참석하게 되어서 많은 준비를 해 갈 수 있을 듯 하네요.


Prompt-x

02/24/2010

1. Introduction

BONDI 는 API 들을 정의하고, 이 API에 접근을 요청하는 Widget 의 접근을
제어하여 악의적인 요청으로 부터 device 를 보호하고 있습니다.

현재 BONDI는 XACML (eXtensible Access Control Markup Language )을
기반으로 compact 한 XML format 을 이용하여 API에 대한 접근을 제어하고
있습니다.
( 참고 : http://bondi.omtp.org/1.1/security/bondixml.rnc.txt - DTD)

이 포스트에서는 복잡한 알고리즘 보다는 실제 접근 제어에 사용되는
efftect value 인 Prompt-x에 대해서 알아보기로 하겠습니다.

2. Prompt-x

effect 에 들어갈 수 있는 value 는 총 5가지가 있다. 그 value 는 다음과 같습니다

  • permit – This effect allows requested access without user interaction.
  • deny – This effect denies requested access without user interaction.
  • prompt-oneshot – This effect allow requested access after explicit confirmation by the user.
  • prompt-session – This effect allow requested access after explicit confirmation by the user.
  • prompt-blanket – This effect allow requested access after explicit confirmation by the user.

이 중 permit과 deny는 별다른 user interaction이 없는 value 이므로
별다른 혼란이 없이 사용되어 집니다.  하지만 prompt-x로 되어 있는 것들은
명백한 사용자의 확인에 의해서만 해당 API에 접근할 수 있는 value입니다.

prompt 의 경우 각 value별로 적용이 가능한 option을 보여주는 대화상자
(dialog)로 user와 interaction을 하게 됩니다. 이제 prompt 의 종류별로
어떠한 조건으로 user와 interaction 하는지 알아 보겠습니다.

2.1 prompt-oneshot

이 value의 spec을 먼저 보면 다음과 같습니다.
“deny always”, “deny this time”, “allow this time”
이 것은 user의 확인을 요하는 dialog에서 위와 같은 list를 주어
user 에게 해당 request 에 대한 확인을 요청하게 됩니다.
그 후 user는 위에 정해진 값 중 한가지를 선택하여 request에 대한
제어를 하게 됩니다.

(prompt-oneshot의 범위 : 해당 API에 대한 요청에 단 한 번만 유효함
                                      이후 동일 API에 대한 요청이 있으면 다시
                                       user의 확인 후 API 접근 가능.
                                      -단, deny always의 경우 WRT engine이 종료 
                                       될 때까지 유지)

2.2 prompt-session

이 value의 spec을 먼저 보면 다음과 같습니다.
prompt-oneshot options plus “deny for this session”,
“allow for this session” 이 것은 prompt-oneshot 에 있는
option에 다음과 같은 “deny for this session”,
“allow for this session” list를 추가하여 user의 확인을
요하는 dialog를 띄워 user 에게 해당 request 에 대한
확인을 요청하게 됩니다. 그 후 user는 위에 정해진 값 중
한가지를 선택하여 request에 대한 제어를 하게 됩니다.

(prompt-session 의 범위 : widget application이 실행되어 있는 상태)

2.3 prompt-blanket

이 value의 spec을 먼저 보면 다음과 같습니다.
prompt-session options plus “allow always”.
이 것은 prompt-session 에 있는 option에 다음과 같은 “allow always” 
list를 추가하여 user의 확인을 요하는 dialog를 띄워 user 에게 해당
request 에 대한 확인을 요청하게 됩니다.
그 후 user는 위에 정해진 값 중 한가지를 선택하여 request에 대한
제어를 하게 됩니다.

(prompt-blanket 의 범위 : WRT engine이 실행되어 있는 상태
                                        단, engine 이 static module 로 구동 될 경우
                                         terminal 이 off 되기 전까지)

3. Opinion

어떠한 보안도 100%로 안전하다고 볼 수는 없지만 현재 BONDI에서는 보안 문제에 상당히 많이 힘쓰고 있습니다. 처음에는 단순히 XML file에 접근제어 값을 넣어 제어하던 방식에서 현재는 signed policy document, provisioning 을 통한 policy update 등 많은 발전이 있었습니다. 그래도 부족한 점이 있겠지만 이렇게 계속 보안에 힘을 쏟는다면 그래도 사용자가 안전하다고 믿고 사용할 수 있는 product가 될 것이라 믿습니다. 마지막으로 제 포스트에 문제가 있으면 답글로 남겨 주시면 리뷰 후 정정 하도록 하겠습니다.

4. Reference

http://bondi.omtp.org/1.1/security/BONDI_Architecture_and_Security_Appendices_v1.1.pdf


팔로우

모든 새 글을 수신함으로 전달 받으세요.