그림1 MSN 알림창

그림1 MSN 알림창

웹에 Notification API가 있으면 좋을 것 같습니다. Notification API가 뭔지 잘 이해가 안간다면 간단하게는 그림 1과 같은 형태의 MSN 알림창을 떠올려 볼 수 있을 것 같습니다. 지정한 API를 호출하면 그림과 같은 알림창이 나타나는거죠. 맥 사용자라면, JavaScript에서 Growl을 볼 수 있으면 더 좋을텐데, 이미 protoGrowl이라는 라이브러리가 있습니다.

차이점이라면 데스크탑에서 알림창을 보여주는 JavaScript API와 브라우저 창 내부에서 사용자가 정의한 조그만 알림창을 시도했던 것입니다. 이 글에서 다룰 것은 전자입니다.

Brian Dunnington 씨가 Windows용 Growl을 개발했고, 최신 버전에서는 JavaScript를 통해 시스템과 통신할 수도 있습니다.

growl.js 라이브러리를 한번 살펴보세요.

관심을 끄는 것은 구현한 부분과 이 작업을 진행한 과정입니다. Dion씨가 그의 생각을 물어봤고, 그래서 그가 다음과 같은 글을 썼습니다:

Windows용 Growl(v1.2 alpha)의 최신 버전의 가장 큰 새로운 기능 중 하나는 브라우저에서 실행하는 웹사이트로부터 알림 메시지를 받을 수 있다는 것입니다. 이 기능을 다루기 위한 최선의 방법을 작업하는데 꽤 많은 시간을 썼습니다. 그리고, 제 사고의 흐름을 공유해야겠다고 생각했습니다.

Growl은 이미 네트웍을 통해 알림메시지를 받을 수 있기 때문에, 네트웍상에서 웹기반 알림 기능을 작성하는 것이 가장 쉬울 것이라고 생각했습니다. Growl은 UDP 상의 단순한 프로토콜을 사용해 네트웍 알림 메시지를 받습니다. 첫번째 장애물이 나타났습니다: 브라우저와 JavaScript는 UDP를 사용할 수 없습니다. 그래서 저는 부가 기능을 만들어야겠다고 생각했습니다. 크로스-브라우저가 되는 해결책을 원했기 때문에, Firefox 확장기능과 ActiveX 플러그인은 제외했습니다. 또한 많은 사람들에게 적용할 수 있는 해결책을 원해서 커스텀 부가기능(Gears같은 것이죠)을 작성하고 싶지는 않았습니다. Flash나 Silverlight이 네트웍을 지원한다는 것은 알고 있었지만, 둘 다 UDP 지원이 되지 않아 제외시켰습니다.

널리 설치되어있고, 크로스 브라우저 확장기능이 되는 유일하게 남은 것이 Java 였습니다. Java는 분명 UDP를 포함한 굳건한 네트워킹을 지원하므로, 저는 그것을 사용하기로 했습니다. 이제 가장 큰 문제는 제가 한번도 Java 애플릿을 만들어 본적도 없고 심지어 Java 코드 한 줄 작성해본 적조차 없다는 것이었습니다. 하지만 문법은 충분히 익숙했고 UDP 패킷을 보낼 작은 애플릿에 넣을만한 좋은 예제 코드도 몇 개 찾아냈습니다. 실제로 꽤 잘 동작했고, 문제를 쉽게 해결한 것 같아서 기분이 몹시 좋았었습니다.

하지만, 물론 그렇게 쉬울 리가 없죠. '동일근원정책(Same-Origin Policy)' 이라는 제약에 부딪히고 말았습니다. 제 로컬호스트에서 잘 작동하던 애플릿이 다른 곳으로 가져가면 바로 보안 예외오류(exception)를 내버리는 것이었습니다. file://url과 data:uri로 인코딩된 애플릿 코드까지 포함해서 CODE와 CODEBASE 속성을 이리저리 조합하는 갖은 노력을 다 했지만, 매번 부딪혔습니다.

애플릿 아이디어를 포기하기 직전에, 만약 로컬 호스트에서 애플릿을 제공할 수 있다면 나중에 로컬호스트와 통신할 수 있을 거라는 사실을 깨달았습니다. 하지만 애플릿을 제공 전용의 간단한 웹서버를 설정하고 설치하는 일은 상상 이상이었습니다. 아아, 그렇게 Java 아이디어는 끝났습니다.

그래서 다시 칠판앞에 돌아왔습니다. 브라우저가 그 간격을 메울 권한을 가지게 할 수 있는게 없을까? 저는 iTunes Music Store(itms://)와 같은 커스텀 프로토콜 핸들러를 시도해보기로 했습니다. 몇 개의 간단한 레지스트리 항목으로 growl:// 프로토콜을 작동하게 할 수 있었습니다. 백그라운드에 상주하는 보조 프로세스가 있어, growl:// URL 링크가 클릭될 때마다 브라우저는 그것을 제 핸들러로 보내주었습니다. 저는 url 정보에 JSON 형태의 문자열로 가능한 어떤 정보든 보낼 수 있게 하기로 했습니다. 다시 한번, 그것은 훌륭히 작동해주어서 좋은 해결책인 것 같았습니다. 하지만 그것은 약점을 가질 수 밖에 없었습니다. 이번 경우의 약점은 사용자의 PC에 프로토콜 핸들러가 설치되었는지 브라우저가 알 방법이 없다는 것이었습니다 - 프로토콜 핸들러가 설치되어있다면 브라우저가 훌륭하게 전달할 것이고, 다 좋습니다. 하지만 프로토콜이 설치되어있지 않으면, Firefox는 '프로토콜 xx는 어떤 프로그램과도 연결되어있지 않으므로, 주소를 열 수 없습니다'와 같은 대화창을 나타낼 것입니다(IE와 Safari는 404 페이지를 보여줍니다). 제가 원한 것은 Growl이 설치된 사용자라면 웹사이트가 통신 기능을 사용할 수 있도록 하는 것이었지 설치가 되어있지 않다고 사용자 경험을 엉망으로 만들어버리는 것은 아니었습니다. 따라서, 이 약점은 치명적이었습니다.

이 부분에서 그 아이디어를 그만두려고 했는데, Java 애플릿을 로컬처럼 제공하는 아이디어가 기억났습니다. 그 해결책을 세세하게 심사숙고하는 동안, '만약에 애플릿을 제공할 로컬 서버를 가지게 된다면, 로컬 서버와 애플릿간의 통신을 생략하면 어떨까?'라고 생각했습니다. 그래서 http://localhost:9889와 같이 접근할 수 있는 Growl이 실행될 때 작동하는 매우 단순한 서버를 구현했습니다. JSON을 전달하는데 url을 사용하자는 아이디어를 다시 떠올렸고, 곧 JSON 형태의 JavaScript 객체를 데이터를 파싱하고 이를 실제 응용프로그램 코드에서 다루는 로컬 서버에 전달할 수 있었습니다. 로컬 서버와 통신하는데 ajax를 쓸 수는 없었습니다(동일근원 정책이 또 걸리더군요), 그래서 감춰진 iframe 기술을 이용하기로 했습니다. 모든 것을 추상화한 작은 js 라이브러리를 작성했기때문에, 응용프로그램 코드에 Growl 라이브러리를 포함했다면 아래와 거의 유사한 JavaScruot 코드를 작성할 수 있게 되었습니다:

[code:js]
Growl.NotificationType someKindOfNotification = new Growl.NotificationType("some kind of notification", true);
Growl.register("Website Name", [someKindOfNotification]);
Growl.notify(someKindOfNotification, 'Notification from the web', 'this is the description', Growl.Priority.VeryLow, false);
물론, 웹 사이트로부터 알림을 받는다는 것은 스팸과 다른 소음의 가능성을 열어두는 것입니다. 그래서 웹 사이트로부터 등록된 응용프로그램들은 알림을 할 수 없도록 기본값을 정했습니다(따라서, 알림을 받겠다는 사용자의 명시적인 허가를 얻어야 합니다). 하지만, 그 부분은 나중에 다룰 다른 주제인 것 같습니다.
from Growl for Windows and Web Notification API on Ajaxian
Posted by 행복한고니 트랙백 0 : 댓글 0

댓글을 달아 주세요