현재 위치

홈 ›› Forums ›› 이슈 ›› 뉴스, 새소식

Ajax: A New Approach to Web Applications

jeongkyu의 이미지
글쓴이: jeongkyu / 작성시간: 화, 2005/03/15 - 6:24오전

Quote:
Ajax: A New Approach to Web Applications
http://www.adaptivepath.com/publications/essays/archives/000385.php

Orkut, Gmail, Google Maps 와 같은 서비스에 사용된 구글의 웹 개발 방법론을 정리하고 있는 흥미로운 글입니다. :D

Forums: 
뉴스, 새소식
FrogLamb의 이미지

글쓴이: FrogLamb / 작성시간: 화, 2005/03/15 - 9:20오전

상당히 멋진 기술입니다만...

문제점이라면 클라이언트쪽 Ajex엔진의 javascript코드가 일반 사용자에게 공개될 수 있는 문제점이 있군요...

----------------------------------------
Kwonjin Jeong

ByB의 이미지

글쓴이: ByB / 작성시간: 화, 2005/03/15 - 9:34오전

FrogLamb wrote:
문제점이라면 클라이언트쪽 Ajex엔진의 javascript코드가 일반 사용자에게 공개될 수 있는 문제점이 있군요...

음.. 그것이 왜 문제가 되죠? :?

----------------------------------------------------------=>
Be supercalifragilisticexpialidocious, run for your life!

FrogLamb의 이미지

글쓴이: FrogLamb / 작성시간: 화, 2005/03/15 - 9:44오전

ByB wrote:
FrogLamb wrote:
문제점이라면 클라이언트쪽 Ajex엔진의 javascript코드가 일반 사용자에게 공개될 수 있는 문제점이 있군요...

음.. 그것이 왜 문제가 되죠? :?


머 기업입장에서는 공개되서 좋을건 없으니까요..
예를들어 GMail같은 경우에는 얼마 안되서 GFS같은 물건이 튀어나오는 경우는 google에서 원하던 결과는 아니었겠죠?

그런걸 제외하면 상당히 멋진 기술임에는 분명합니다 :D

----------------------------------------
Kwonjin Jeong

whitekid의 이미지

글쓴이: whitekid / 작성시간: 화, 2005/03/15 - 11:11오전

예전에 몇가지 테스트 해 보았는데 잘 되더군요... 그런데 이 기술은 XMLRequest에서 HTML을 리턴해주게 되어있는데... XMLRPC와 비슷한 측면도 없지않아 있더군요. 리턴값을 base64_string으로 주면 되니깐...

What do you want to eat?

atie의 이미지

글쓴이: atie / 작성시간: 금, 2005/03/25 - 9:29오전

흥미로운 기술들의 조합이군요. (서버쪽 프로그램을 하는 저로서는 서버는 xml문서만 제공하면 된다는 것에 특히 눈길이 갑니다.)

그리고, XMLHttpRequest에 대한 다음의 인용된 부분이 왜 구글이 이걸 적용했는지를 간단하지만 잘 설명을 해주는 군요.

Quote:

...
The Basics

Due to its history, and not yet being embodied in any public standard (although something similar is in the works for the proposed W3C DOM Level 3 Load and Save spec), there are two distinct methods for instantiating an XMLHttpRequest object. For Internet Explorer, an ActiveX object is used:

var req = new ActiveXObject("Microsoft.XMLHTTP");

For Mozilla and Safari, it's just a native object:

var req = new XMLHttpRequest();

Clearly, as a result of this inconsistency, it's necessary to fork your code based on support for the appropriate object.
...


http://www.xml.com/pub/a/2005/02/09/xml-http-request.html

Echo2 : Ajax-based Rendering engine
http://www.nextapp.com/products/echo/

----
I paint objects as I think them, not as I see them.
atie's minipage

죠커의 이미지

글쓴이: 죠커 / 작성시간: 금, 2005/03/25 - 1:35오후

FrogLamb wrote:
ByB wrote:
FrogLamb wrote:
문제점이라면 클라이언트쪽 Ajex엔진의 javascript코드가 일반 사용자에게 공개될 수 있는 문제점이 있군요...

음.. 그것이 왜 문제가 되죠? :?


머 기업입장에서는 공개되서 좋을건 없으니까요..
예를들어 GMail같은 경우에는 얼마 안되서 GFS같은 물건이 튀어나오는 경우는 google에서 원하던 결과는 아니었겠죠?

그런걸 제외하면 상당히 멋진 기술임에는 분명합니다 :D

GMail의 javascript가 없었다고 하더라도 GFS는 나왔을 것입니다. XMLHttpRequest 기술 때문에 GFS가 나온게 아니라 1기가라는 용량을 보고 GFS가 나온 것이니깐요.

구글이 그런 기술이 나올지 몰랐을까요? 오히려 더 좋아했을 것입니다. :-) google은 이제 api 공개를 넘어서 open source project도 시작하고 있습니다. 자극받은 yahoo도 자신들의 컨텐츠를 api를 통해 공개하기 시작하더군요.

구글 입장에서는 공개를 꺼릴 것이 없습니다. 공개될 수록 구글 플랫폼의 시장지배가 더 강력해지기 때문입니다. 아래아한글이 시장지배력을 잃는 것은 그 파일이 비공개되어 있는 것도 한 원인입니다. 5년 전에 hwp 파일 포맷을 공개했으면 전체적인 hwp 파일의 시장 지배력은 절대적이었을 테고 시장자체를 넓혔기 때문에 아래아한글은 더 많이 팔렸을 것입니다.

- 죠커's blog / HanIRC:#CN

jinoos의 이미지

글쓴이: jinoos / 작성시간: 금, 2005/03/25 - 2:30오후

CN wrote:
FrogLamb wrote:
ByB wrote:
FrogLamb wrote:
문제점이라면 클라이언트쪽 Ajex엔진의 javascript코드가 일반 사용자에게 공개될 수 있는 문제점이 있군요...

음.. 그것이 왜 문제가 되죠? :?


머 기업입장에서는 공개되서 좋을건 없으니까요..
예를들어 GMail같은 경우에는 얼마 안되서 GFS같은 물건이 튀어나오는 경우는 google에서 원하던 결과는 아니었겠죠?

그런걸 제외하면 상당히 멋진 기술임에는 분명합니다 :D

GMail의 javascript가 없었다고 하더라도 GFS는 나왔을 것입니다. XMLHttpRequest 기술 때문에 GFS가 나온게 아니라 1기가라는 용량을 보고 GFS가 나온 것이니깐요.

구글이 그런 기술이 나올지 몰랐을까요? 오히려 더 좋아했을 것입니다. :-) google은 이제 api 공개를 넘어서 open source project도 시작하고 있습니다. 자극받은 yahoo도 자신들의 컨텐츠를 api를 통해 공개하기 시작하더군요.

구글 입장에서는 공개를 꺼릴 것이 없습니다. 공개될 수록 구글 플랫폼의 시장지배가 더 강력해지기 때문입니다. 아래아한글이 시장지배력을 잃는 것은 그 파일이 비공개되어 있는 것도 한 원인입니다. 5년 전에 hwp 파일 포맷을 공개했으면 전체적인 hwp 파일의 시장 지배력은 절대적이었을 테고 시장자체를 넓혔기 때문에 아래아한글은 더 많이 팔렸을 것입니다.

XMLHTTPRequest 와 1기가라는 메리트 두가지 다 이유가 있었다고 보는데요.. 그중에 비중은 XMLHTTPRequest 쪽이 훨신 커다란 이유라고 생각합니다.

단순한 웹메일을 가지고 만들기는 쉽지 않은 문제니까요..

원론으로 돌아가서 생각해 보면, ajax 는 실제 새로운 패러다임이 아닙니다. 블로그 처럼 기존에 개인 펼침게시판을 '블로그' 라는 새로운 개념으로 포장했듯이 ajax 역시 XMLHTTPRequest 를 ajax 라는걸로 포장한듯한 느낌입니다.

또한 XMLHTTPRequest 역시 MS의 MSXML의 HTTPRequest를 본따만든 기능이 발전한거였죠.

ajax이 좋은 기술이건아니건 중요한건 ajax를 어느순간에 적용하느냐가 관건인것 같습니다. 그런 관점에서 google maps는 탁월한 선택이였죠.

목적을 찾아서... jiNoos

creativeidler의 이미지

글쓴이: creativeidler / 작성시간: 금, 2005/03/25 - 2:34오후

글쎄요. 제 생각에는 단순 웹메일로도 얼마든지 가능한 것 같습니다. 그것도 별로 어렵지 않게요. 어차피 HTTP 프로토콜로 날리기만 하면 되는 거 아니겠습니까. 대부분의 언어에서 HTTP 프로토콜 구현은 다 나와 있으니 할 일은 단지 요청/응답을 적절히 포장하는 것 뿐이고 이 점에서는 뭘 쓰든 별 차이 없죠.

죠커의 이미지

글쓴이: 죠커 / 작성시간: 금, 2005/03/25 - 2:37오후

jinoos wrote:
XMLHTTPRequest 와 1기가라는 메리트 두가지 다 이유가 있었다고 보는데요.. 그중에 비중은 XMLHTTPRequest 쪽이 훨신 커다란 이유라고 생각합니다.

너무 기술적으로 보신 것 같습니다.

1기가 메일이란 것을 듣고 GFS를 생각했을테고 그 후에 XMLHttpRequest를 보고 이렇게 구현하면 되겠다고 생각했을 것입니다. (XMLHttpRequest를 이용해서 구현한것은 맞나요?)

만약에 XMLHttpRequest가 없었더라도 다른 구현 방식을 찾아냈을 것입니다.

다시 말하면 아래와 같은사고를 거쳤을 거라는 것이죠.

(컨셉)
A: 구글 메일이 1기가이다.
B: 1기가의 용량을 웹하드로 이용할 수 있을 것이다.

(구현)
C: 살펴보니 XMLHttpRequest로 구현되어 있다.
D: XMLHttpRequest로 구현해서 만들자.

(결과)
E : 구글 메일로 GFS를 만들었다.

C가 없다고 하더라도 C,D만 바뀔뿐 처음과 끝은 같을 것 같지 않습니까? :-) 그 컨셉과 제품이 동일한데 XMLHttpRequest가 그렇게 큰 의미를 가질까요?

- 죠커's blog / HanIRC:#CN

jinoos의 이미지

글쓴이: jinoos / 작성시간: 금, 2005/03/25 - 3:13오후

CN wrote:
jinoos wrote:
XMLHTTPRequest 와 1기가라는 메리트 두가지 다 이유가 있었다고 보는데요.. 그중에 비중은 XMLHTTPRequest 쪽이 훨신 커다란 이유라고 생각합니다.

너무 기술적으로 보신 것 같습니다.

1기가 메일이란 것을 듣고 GFS를 생각했을테고 그 후에 XMLHttpRequest를 보고 이렇게 구현하면 되겠다고 생각했을 것입니다. (XMLHttpRequest를 이용해서 구현한것은 맞나요?)

만약에 XMLHttpRequest가 없었더라도 다른 구현 방식을 찾아냈을 것입니다.

다시 말하면 아래와 같은사고를 거쳤을 거라는 것이죠.

(컨셉)
A: 구글 메일이 1기가이다.
B: 1기가의 용량을 웹하드로 이용할 수 있을 것이다.

(구현)
C: 살펴보니 XMLHttpRequest로 구현되어 있다.
D: XMLHttpRequest로 구현해서 만들자.

(결과)
E : 구글 메일로 GFS를 만들었다.

C가 없다고 하더라도 C,D만 바뀔뿐 처음과 끝은 같을 것 같지 않습니까? :-) 그 컨셉과 제품이 동일한데 XMLHttpRequest가 그렇게 큰 의미를 가질까요?

접근 방법에 차이가 아닐까요?

A : 소스가 뭔지 복잡하군 뭘로 만든거야, 도데체.
B : 훗 XMLHTTPRequest 였군. 좀 가지고 놀아볼까?
C : 1기가나 되니 파일시스템으로 만들어 보는건 어떨까.
D : 구글 메일로 GFS를 만들었다.

스토리 짜는거야 만들기 나름 아니겠습니까? ^^.

html 소스를 파싱하고 api 를 생산해내는 삽질보다 xmlHTTPRequest 를 호출하는 js 를 보면서 api를 생산하는것이 얼마나 효율적이고 깔끔한 작업인지는 예상이 가능하지 않던가요?

가능은 하지만 1기가 이기때문에 GFS가 나와야 될 필요는 없습니다. 100메가는 FS가 나오지 못하는 이유가 없는거죠. 구조적인 Request, Response 시스템이 있었기에 좀더 가능성이 넓어진것일뿐입니다.

원론에서 계속 벗어나네요. ^^;

목적을 찾아서... jiNoos

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 금, 2005/03/25 - 3:49오후

그 부분에 대해서는 지금 서비스중인 1기가 메일 중에서 GFS 같은 플러그인이 존재하는 빈도를 살펴보면 되지 않을까요?
가장 쉬우니까 만들었다..그런 점은 분명히 있을거라 생각합니다.

nohmad의 이미지

글쓴이: nohmad / 작성시간: 금, 2005/03/25 - 7:32오후

jinoos wrote:
접근 방법에 차이가 아닐까요?

A : 소스가 뭔지 복잡하군 뭘로 만든거야, 도데체.
B : 훗 XMLHTTPRequest 였군. 좀 가지고 놀아볼까?
C : 1기가나 되니 파일시스템으로 만들어 보는건 어떨까.
D : 구글 메일로 GFS를 만들었다.

스토리 짜는거야 만들기 나름 아니겠습니까? ^^.

html 소스를 파싱하고 api 를 생산해내는 삽질보다 xmlHTTPRequest 를 호출하는 js 를 보면서 api를 생산하는것이 얼마나 효율적이고 깔끔한 작업인지는 예상이 가능하지 않던가요?

가능은 하지만 1기가 이기때문에 GFS가 나와야 될 필요는 없습니다. 100메가는 FS가 나오지 못하는 이유가 없는거죠. 구조적인 Request, Response 시스템이 있었기에 좀더 가능성이 넓어진것일뿐입니다.

원론에서 계속 벗어나네요. ^^;

계속 주제와 상관없는 말꼬리 잡아서 죄송합니다만 이런 종류의 작업에 굳이 프레임 삽질에다 알아보기 힘들게 꼬아놓은(obfuscated) HTML 소스를 보면서 작업할 것 같지는 않군요. 그냥 http 패킷을 덤프하면 어떤 요청이 오고가는지 다 보이거든요. ;) HTTP 레벨에서 보자면 XMLHTTPRequest나 일반 요청이나 아무 차이 없습니다.

----
http://nohmad.tumblr.com/

둘러보기