Google에서 또 일을 저지른 것 같습니다(물론, 좋은 의미입니다). 간단히 본문을 요약하자면, Prototype, jQuery등의 주요 Ajax 프레임웍을 자기네들이 호스팅해서 전세계 개발자들에게 제공하겠다는 것입니다.

버전관리, 버그패치, 트래픽 다 감당하겠다는 거죠. 심지어 오래된 버전까지 그냥 끌어다 쓸 수 있으니 속도만 보장된다면(본문에는 세계 전역에 분포된 CDN을 사용하므로 빠를 것이라고는 합니다만..), 정말 간편하게 사용할 수 있을 것 같습니다. 아직 관련 소식을 다른 곳에선 들은 적이 없네요. 제가 보기엔 꽤 큰 사건임에 분명해보이는데요. :)
사용자 삽입 이미지
________________
Google에서 Prototype, Script.aculo.us, jQuery, Dojo, MooTools와 같은 유명 프레임웍들을 사용하는 Ajax 응용프로그램을 만들 수 있는 Google AJAX Libraries API발표했습니다.

응용프로그램을 작성할 때마다 매번 파일을 다운로드 받아서 설치하기를 반복하실텐데요, 글을 쓴 Dion씨는 무려 자신의 응용프로그램에서 33개의 prototype.js 복사본을 사용하고 있다고 합니다. 사이트가 달라질 때마다 매번 다운로드 받게 되는거죠. 얼마나 큰 낭비입니까!

또한, Steve Souder씨는 성능면에서 우리가 이러한 라이브러리를 제공함에 있어 얼마나 잘못하고 있는지 지적한 바 있습니다. 개발자로서 우리는 캐싱을 정확하게 해서 파일이 필요할 때만 다운로드되도록 해야합니다. 또한 gzip 압축이 가능한 브라우저라면 압축 전송을 해야합니다. 아, 조금이라도 용량을 줄이기 위해 최소화 버전도 사용해야 할 것입니다. 파일의 버전 관리도 제대로 해야죠. 아니면, 수없이 많은, 때론 파일 끝에 조금씩 입맛에 맞게 수정을 가한, 버전이 없는 jquery.js 파일을 발견하고, 캐시는 전혀 제대로 설정되어있지 않아 아무런 이유도 없이 파일을 항상 전송할 겁니다.

Dion씨는 Google에 입사해서 이런 것들을 도울 수 있을 것 같다고 생각했다고 합니다. 우리가 이런 파일들을 호스팅하면 어떨까? 모든 사람이 바로 이런 혜택을 받게 되었겠죠:
  • 제대로 된 캐싱, Google이 한번만 작업하면 개발자들이 할 일은 아무것도 없음
  • Gzip 압축
  • 최소화 버전 제공
  • Google에 의해 호스팅되는 파일들은 세계 전역에 걸쳐있는 분산 CDN에서 제공되므로, 파일은 사용자들에게 "근접"해있음.
  • 서버가 빠름
  • 똑같은 URL을 사용하므로, 응용프로그램의 상당 부분이 Google의 인프라를 사용한다면, 누군가 여러분의 응용프로그램에 접근할 때 그 파일은 이미 로딩되어있을 것!
  • 여러분이 보내고 받는 헤더와 관련된 미묘한 성능(그리고 보안) 문제 해결. 특정 도메인을 사용하고 있으므로(주의: google.com은 아닙니다!), 쿠키나 다른 쓸데없는 헤더가 전송되지 않으므로 귀중한 트래픽 절약
이게 Google이 AJAX Libraries API를 출시한 이유입니다. 몇 개의 유명 오픈소스 프레임웍 진영과 대화한 결과 그들은 모두 이 아이디어를 흥미로워했습니다. 그래서 그들과 이 작업을 시작했으며, 이제 여러분은 Google의 서버에서 그들의 훌륭한 작업물에 접근할 수 있습니다.

세부사항

라이브러리에는 두 가지 방법으로 접근할 수 있고, 둘 다 라이브러리를 호스팅하는 고통 - 정확하게는 캐시 헤더를 설정하고 최근 버그 패치들을 적용하도록 꾸준히 업데이트 하는 일 등 - 을 덜어주는 방법입니다.

첫번째 방법은 간단하게 표준 <script src="..."> 태그를 이용해서 스크립트에 접근하는 방법입니다.

예를 들면, Prototype 1.6.0.2 버전을 읽어들이려면 HTML에 아래와 같은 코드를 입력하면 됩니다.
[code:js]
<script src="http://ajax.googleapis.com/ajax/libs/prototype/1.6.0.2/prototype.js"></script>
두번째 방법은 Google AJAX API 로더의 google.load() 메소드를 이용하는 것입니다.

아래는 간단한 검색 매시업을 위해 jQuery를 읽고 사용하는데에 해당 기술을 사용한 예제입니다.
[code:js]
<script src="http://www.google.com/jsapi"></script>
<script>
  // Load jQuery
  google.load("jquery", "1");
 
  // on page load complete, fire off a jQuery json-p query
  // against Google web search
  google.setOnLoadCallback(function() {
    $.getJSON("http://ajax.googleapis.com/ajax/services/search/web?q=google&;v=1.0&;callback=?",
 
      // on search completion, process the results
      function (data) {
        if (data.responseDate.results &&
            data.responseDate.results.length>0) {
          renderResults(data.responseDate.results);
        }
      });
    });
</script>
아마 사용한 버전이 그냥 "1"라는 것을 알아차리셨을 것입니다. 이는 스마트 버저닝 기능으로, 여러분의 응용프로그램에서 필요한 앞자리만 지정할 수 있도록 하고 있습니다. 버전 필드를 입력하지 않음으로써, 필드에 와일드 카드를 사용한 것입니다. 간단히, 이런 버전들을 생각해보세요: 1.9.1, 1.8.4, 1.9.2

"1.8.2"라는 버전을 지정하면 정확한 버전이 선택됩니다. 이는 사용할 버전 전체를 지정했기 때문입니다. "1.8"과 같이 버전을 지정하면 1.8 브랜치에서 가장 높은 릴리스 버전인 1.8.4 가 선택됩니다. 같은 이유로, "1"을 요청하면, 실제로 읽히는 버전은 "1.9.1" 입니다.

아셔야 할 것은 이러한 버전관리 시맨틱이 google.load를 사용할 때와 직접 script url을 사용할 때 똑같은 방식으로 작동한다는 것입니다.

기본적으로, 로더가 되돌려주는 JavaScript는, 지원되는 버전이 있다면, 최소화 되어있습니다. 그러므로, 위의 예제는 jQuery의 최소화된 버전을 반환할 것입니다. 만약 최소화 되지 않은 JavaScript 파일을 원하신다면 "uncompress" 파라미터를 추가하시면 됩니다.
[code:js]
google.load("jquery", "1.2", {uncompressed:true});
오늘은 라이브러리들의 현재 버전으로 시작하지만, 앞으로는 현재부터의 모든 버전을 제공하겠다고 합니다.

현재 지원하는 라이브러리의 전체 목록은, 문서 부분을 보시기 바랍니다.

Dion씨가 자신들이 작업한 것에 대해 두 장의 짧은 슬라이드를 보여주셨습니다.


미래

이것은 단지 시작일 뿐입니다. Google에서는 유용하게 사용할 수 있도록 보다 많은 라이브러리들을 추가하려고 합니다. 또한, 약간의 관심만 있으시면 어떻게 이들이 더 나아갈 수 있는지 아시게 될 것입니다.

이것이 잘 사용되면 다음번에는 이러한 라이브러리들을 자동으로 읽어들일 수 있도록 브라우저 벤더들과 작업할 것이라고 합니다. 그러면, 해당 URL에 접근했을 때, 자동으로 라이브러리를 읽어들일 수 있게 됩니다. 심지어는 로컬에 있는 특별한 JIT된 것까지도요. 그러므로, 네트웍은 전혀 사용하지 않게 되죠! 또한, 브라우저는 이 서비스가 가능한 IP 주소를 가지고 있을 수 있어 DNS 탐색도 하지 않게됩니다. 오래 유지되는 JavaScript 라이브러리를 위한 브라우저 캐시도 이런 URL을 사용합니다.

이러한 것들이 일어난다면 웹 개발자들에게는 어떤 의미일까요? 항상 표준 라이브러리를 다시 다운로드받아야 했던 늘상 있어왔던 부담에서 벗어날 수 있습니다. 다른 어떤 플랫폼에서 이런 것이 가능했을까요? Java 응용프로그램을 실행할 때마다 매번 JRE를 다운로드 받아야 한다고 생각해보세요! 만약 그런 부담을 덜 수 있다면, 필요한 기능을 만드는데 보다 많은 시간을 투자할 수 있고, 실제 다운로드 크기에 대해서 고민할 시간은 줄일 수 있습니다.

감사의 말씀
(이 부분은 번역 생략하겠습니다. ^^;;)

from Announcing AJAX Libraries API: Speed up your Ajax apps with Google's infrastructure on Ajaxian
Posted by 행복한고니 트랙백 5 : 댓글 4

댓글을 달아 주세요

  1. addr | edit/del | reply BlogIcon Gloridea 2008.06.04 17:05 신고

    헉, 어제 집에 가는 버스 안에서 생각했던건데... ㅋㅋ; 놀랍군요.

    • addr | edit/del BlogIcon 행복한고니 2008.06.05 00:55 신고

      비슷한 아이디어를 작년 중반쯤에 생각해서 논의했던 적도 있었어요. 결국은 "누가 관리할건데"라는 문제에 부딪혀 무산되고 말았지만요.

      생각하면 실천할 수 있는 환경이 좀 부럽습니다. ^^;;

  2. addr | edit/del | reply BlogIcon ikspres 2008.06.05 09:18

    좋군요. 구글이 오랜만에 나이스한 일을 하나 했네요.

  3. addr | edit/del | reply BlogIcon Gloridea 2008.06.07 18:30 신고

    행복한고니 // 그랬군요 ^^; 함께 차차 만들어나갈 수 있을거라고 생각합니다. :-)

그림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

댓글을 달아 주세요

구글의 Location API

2008. 5. 15. 00:50 from [IT] Web Tech
Gears 커뮤니티에서 Geo Location API에 대해 논의중입니다. Aaron Boodman씨에 따르면 이 API는 "W3C WebAPI 그룹에 최근에 제안되었다"고 합니다.

Aza Raskin씨는 오늘 API에 대한 자신의 생각을 다룬 Firefox에서의 지리좌표와 그 너머라는 글을 썼습니다.
제안된 API를 살펴보는 것도 꽤 재밌을 것 같습니다:

Gears 예제
[code:js]
var geo = google.gears.factory.create('beta.geolocation');

// Get the position.
geo.getCurrentPosition(function(position) {
 updateMap(position.latitude, position.longitude);
});

// Watch the position over time.
var watchId = geo.watchPosition(function(position) {
 updateMap(position.latitude, position.longitude, position.accuracy);
});

geo.clearWatch(watchId);

// Only get the position if the last known position is more than a minute old.
var now = new Date().getTime();
var threshold = now - 60000;

if (geo.lastPosition &&
 geo.lastPosition.timestamp.getTime()> threshold) {
 updateMap2(geo.lastPosition);
} else {
 loc.getCurrentPosition(function(position) {
 updateMap2(position);
 });
}
Aza 예제
[code:js]
var geolocator = new navigator.GeolocationRequest();
geolocator.request(function(location) {
  alert( location.latitude + ', '+ location.longitude + ", " + location.accuracy );
});

var geolocator = new navigator.GeolocationRequest();
geolocator.request({
  success: function(location) { /* We've got the location! */ },
  error: function(err){ /* There was an error getting location. */ },
  accuracy: "neighborhood"
});
개인정보보호나 정확성에 관한 토의도 많습니다. Apple도 자신들만의 위치 관리자를 가지고 있다고 하는군요.

이들 중 어느 하나로 통합이 되어, 브라우저에서 지리좌표 API를 사용할 수 있었으면 좋겠습니다. 한 개의 단순한 추상 객체가 수많은 훌륭한 응용프로그램으로 되는 법이죠.

from Location APIs: The Discussion on Ajaxian
Posted by 행복한고니 트랙백 0 : 댓글 0

댓글을 달아 주세요

from A wishlist for Ajax APIs on Ajaxian

Highland Fling 컨퍼런스에 참석하고 글쓴이가 Ajax API를 제안했다고 합니다.

보다 자세한 정보는 블로그에 있습니다: 훌륭한 Ajax API 설계.


TAG API
Posted by 행복한고니 트랙백 0 : 댓글 0

댓글을 달아 주세요

from Flinging APIs in the Highlands on Ajaxian

(주: 글의 Rushgrove씨가 참여한 컨퍼런스 이름이 The Highland Fling 라서 제목을 언어유희적으로 지은 것 같습니다. Highland 는 스코틀랜드 고지高地 지방을 말하기도 하고 실제로 컨퍼런스가 스코틀랜드에서 열렸습니다)

Gareth Rushgrove씨가 API 설계에 대해서 많은 말을 했다는데... 프리젠테이션입니다. (주: 이걸 보고서는... -_-;;) 우리가 웹과 인터랙션하는 다양한 방법에 대해 생각해보는 것부터 시작했다고 합니다. 그는 몇몇 유명한 API (예, Flick, Twitter) 를 보고 설계에 대한 일반적인 진리를 찾아내려고 했습니다.

API는 이렇게.

  • Prodable (주: 찌를 수 있어야 한다는데 PT만 봐서는 잘 모르겠습니다)
  • Hackable (주: 원본을 그대로 둔 채 외부에서 수정할 수 있도록 되어야 한다는 것인데, 한 단어로 설명하기가 어렵네요)
  • 다양한 언어를 지원
  • 개방적으로
  • 투명하게
  • 명확하게


Posted by 행복한고니 트랙백 0 : 댓글 0

댓글을 달아 주세요