Mozilla 한국 커뮤니티

맨날 액티브엑스대문에 안되다고만 하는데 도데체 액티브엑스에 해당하는 웹표준이 있기는 한건가요? 만약 잇다면 그걸 정말 표준화하도록 우리나라 웹사이트에서 확산되도록 캠페인을 벌여야하지 않을까요?

엑티브 엑스는 표준이 없습니다.
그 이유로는 윈도우에서만 작동되기 때문입니다.
타 os에서도 작동한다면 표준이 생기겠죠?

ulsanin wrote:맨날 액티브엑스대문에 안되다고만 하는데 도데체 액티브엑스에 해당하는 웹표준이 있기는 한건가요? 만약 잇다면 그걸 정말 표준화하도록 우리나라 웹사이트에서 확산되도록 캠페인을 벌여야하지 않을까요?

캠페인을 벌이면 좋겠지만, 대다수의 유저들이 이런 사항에는 관심이 없다는게 문제입니다.

ulsanin wrote:맨날 액티브엑스대문에 안되다고만 하는데 도데체 액티브엑스에 해당하는 웹표준이 있기는 한건가요? 만약 잇다면 그걸 정말 표준화하도록 우리나라 웹사이트에서 확산되도록 캠페인을 벌여야하지 않을까요?

애초에 MS가 윈도우에서(특히 IE에서) 돌아가는 걸 목표로 만든 기술이라 다른 OS에선 구현도 안되고.. 구현 될 일도 없을겁니다.

표준이라기 보다는 IE에서 구동되는 기능일 뿐이죠.
액티브X를 표준화하는건 애초에 불가능하고.. 다른 대체할 걸 만드는게 낫죠.

액티브 X 가 윈도우에서만 돌아가거나 표준화가 안된다거나
하는걸 이야기 하고자 하는게 아니라,

그렇게 쓰지 말라고 이야기를 한다면 그걸 대체할 기술이 뭐냐 라고
묻는것 같은데요?
(몰라서 물어보는게 아니라 아는데 안쓰면 대책은 뭐냐 라는거겠죠...)

그건 대체적인 웹제작자들의 의문점이 아닐까 싶기도 합니다.
액티브 X 를 안쓰고 다른 기술로 액티브 X 만큼 제작이 쉽고,
다양한 기능을 탑재한채로, 더불어 크로스 플랫폼 까지 완벽하게
지원되는게 있을까의 의문이요...

대책이 자바라고는 하지만...
ㅡ ㅡ 자바로 만들어진거라고는 아직 오에카키 빼고는 본적이 없는것 같구요.

뭐 간단한 어플리케이션의 경우엔 플래시로도 만들수 있고...
점점 X-internet 이 많이 등장하고 있으니깐 액티브X 가 점점 필요없어지지
않을까 싶기도 하구요.

액티브 X 가 필요없다고 하는 사람들이야 당연 자기가 그쪽 파니깐 그러는거고...
현실적으로 아직은 액티브 X 나 윈도우를 버리기 힘들죠.
단지 점차적으로 바꿔나감으로서 바뀔 수 있다고 보구요.
아직까지 사용하면 안된다고 못박아서 이야기하기엔 무리라고 생각합니다.

AJAX 가 아닐지.

ActiveX를 왜 사용하는가부터 따져야 대체를 논할 수 있지 않을까요?

ActiveX는 결국, "클라이언트PC에서 특정한 프로그램을 수행시키기"를 목적으로 합니다.
그러므로, 그 "특정한 프로그램"이 무엇이냐, 어떻게 구현되느냐에 따라 다르겠지요.

첫번째 경우,
예를 들어, "인터넷 뱅킹". (정확히 말하자면, 인터넷 뱅킹을 위한 사용자 인증 및 암호화겠지요.)이건 굳이 ActiveX를 쓰지 않더라도 Java등의 플러그인 기술을 써서 제작할 수 있었을 겁니다. 필요하다면, 디컴파일의 위험성이 있지만 플래쉬로도 만들 수 있겠지요. 혹은, 브라우저별로 각각 만들 생각만 있어도, 모질라 플러그인이나 오페라 플러그인 등을 제공할 수 있습니다. 이런 경우 ActiveX의 문제는 ActiveX로 제공하는 것이 문제가 아니라, ActiveX만 제공하는 것이 문제겠지요.

이 문제는 좀 이상한 순환논리에 빠지게 만듭니다. ActiveX만 만들어놓고는, ActiveX밖에 이용할 수 없으니 ActiveX만 쓰자 라는 말이 되거든요. 웹표준의 입장에서는, 다른 대안도 있을테니 그것도 제공해달라. 는 것입니다. ActiveX를 폐기하고 다른 대안을 선택하라..는 입장은 이 경우는 아닙니다.

두번째 경우는,
애초에 ActiveX(혹은 그에 상응하는 대체기술) 자체가 필요없는 경우에도 그것에만 의존하는 경우입니다. 예를 들어, "파일 업로드"를 하는데, 굳이 ActiveX(혹은 그에 상응하는 어떤 것)을 쓰지 않더라도 기본 HTML 폼만으로도 가능합니다. 물론 ActiveX 파일업로드 기능을 이용해서 무지무지 이쁘고 편리한 웹이용이 가능할 겁니다. 하지만, 서비스 특성상 "반드시" 그것에만 의존해야하는 경우가 아니라면, 비 ActiveX용 브라우저를 위한 대체 fallback도 제공해달라는 주장입니다. 역시 ActiveX만 제공하는 것이 문제이며, 아주 특별한 이유가 없다면 "불편하고 안예쁘지만" 비사용자를 위한 기본 기능도 함께 제공해야 한다는 주장이죠.

세번째 경우는,
이번에는 반드시 ActiveX를 써야하는 경우를 말해보죠. 저는 그 대표적인 예로 게임을 들겠습니다. 어차피 게임은 OS 종속적인 경우가 많습니다. 이런 게임의 로더(웹에서 바로 실행)를 ActiveX로 구현하는 것은 필요하고 맞습니다. 아무도, Windows XP 클라이언트에서만 실행가능한 온라인게임 로더기능을 웹표준화라는 미명하에 매킨토시용 FF에서 구현해달라고 주장하지는 않습니다. 뭐, 이왕이면, "이 게임은 Windows에서만 실행가능하니 IE로 접속해서 이용해주세요." 문구 정도를 덤으로 띄워주면 감사하겠죠.

즉, ActiveX로 구현하려는 목적이 특정OS(Windows)에 종속적인 프로그램의 실행이 아니라면, 굳이 ActiveX"만" 만드는 것은 곤란하다는 뜻입니다.

이렇게 보고나면, ActiveX를 써야할 곳과 안 써야할 곳이 나뉘어지죠.
말장난 같지만,
ActiveX를 써야하는 곳에는 ActiveX를 대체할만한 기술따위 없습니다. (애초에 대체기술이 필요할 이유도 없구요.)
반대로 ActiveX를 안써야하는 곳은 원래 ActiveX가 아니래도 구현가능한 대체기술들이 있습니다. Java 애플릿일 수도 있고, AJAX일 수도 있고, 플래쉬일 수도 있고, 기본 HTML일 수도, 브라우저별 플러그인일 수도 있겠죠.
다른 말로 표현하자면, 굳이 ActiveX로 구현안해도 되는 부분은 일부러 ActiveX로 구현하지 말자 입니다.

개발자분들께 묻고 싶습니다. 지금 만들려는 ActiveX기능은 Windows가 아니면 전혀 꿈도 못꿀 그런 기능인가요?
네. 리눅스 환경에서 Windows 미디어플레이어를 제어하는 기능은 꿈도 못꿀 그런 기능 맞습니다. 그런 경우라면 ActiveX 쓰세요. 기왕이면 다른 브라우저 사용자용 대체 수단도 같이 주시면 좋겠죠. 예를 들어.. ActiveX를 사용한 구간반복같은 기능은 없더래도, QuickTime을 이용한 단순 재생기능 정도는 ActiveX없이 일반 HTML 코드만으로도 충분하죠. Windows에서 IE로 접속하면 ActiveX를 이용한 미디어플레이어를 띄워주고, 리눅스에서 FF로 접속하면 QuickTime을 띄워주고.. 그러자는 주장입니다.
만약 이것이 비즈니스 모델과 연관된 중요한 부분이라서 대체해줄 수 없다면 최소한 다른 브라우저로 접속했을 때에는 적절한 안내문을 표시해주고 사이트가 멈추거나 깨지는 일 등은 없게 만들어주면 충분할 일이죠.

사용자에게 "원하지 않는 친절"을 강요하는 경우라면, "불친절한 대체수단"이래도 함께 제공해달라는 것이 웹표준화 쪽의 주장입니다. (대개의 경우, 기획자의 생각과는 달리 사용자들은 그다지 불편하지 않다고 느끼는 경우도 많습니다.) 생각하시는 것처럼 ActiveX를 완전 없애자는 소리는, "불필요한 곳 까지 ActiveX를 사용하지는 말자"로 바꿔 들어주시면 좋겠습니다.(뭐, 아시다시피, 말이란게 입밖에 나오면 처음 생각했던 의도와는 달라지거든요. )

답변이 되었는지 모르겠네요.

바이런 wrote:
대책이 자바라고는 하지만...
ㅡ ㅡ 자바로 만들어진거라고는 아직 오에카키 빼고는 본적이 없는것 같구요.

님의 경험이 웹의 모든 것이라고 단정하지는 마시기 바랍니다.

액티브 X 가 필요없다고 하는 사람들이야 당연 자기가 그쪽 파니깐 그러는거고...
현실적으로 아직은 액티브 X 나 윈도우를 버리기 힘들죠.
단지 점차적으로 바꿔나감으로서 바뀔 수 있다고 보구요.
아직까지 사용하면 안된다고 못박아서 이야기하기엔 무리라고 생각합니다.

웹이 무엇인지에 대한 개념 형성이 제대로 안 된 상태에서 (웹의 역사에 대해 공부하거나 심지어 들어 본 적도 없으며) 데스크탑 프로그램을 위해 배운 기술을 그대로 웹에서 똑같이 쓰려고 하니까 그런 식의 결론이 나오겠지요.

빛알갱이 wrote:

바이런 wrote:
대책이 자바라고는 하지만...
ㅡ ㅡ 자바로 만들어진거라고는 아직 오에카키 빼고는 본적이 없는것 같구요.

님의 경험이 웹의 모든 것이라고 단정하지는 마시기 바랍니다.

액티브 X 가 필요없다고 하는 사람들이야 당연 자기가 그쪽 파니깐 그러는거고...
현실적으로 아직은 액티브 X 나 윈도우를 버리기 힘들죠.
단지 점차적으로 바꿔나감으로서 바뀔 수 있다고 보구요.
아직까지 사용하면 안된다고 못박아서 이야기하기엔 무리라고 생각합니다.

웹이 무엇인지에 대한 개념 형성이 제대로 안 된 상태에서 (웹의 역사에 대해 공부하거나 심지어 들어 본 적도 없으며) 데스크탑 프로그램을 위해 배운 기술을 그대로 웹에서 똑같이 쓰려고 하니까 그런 식의 결론이 나오겠지요.

뭐가 불만 이라서 이딴식으로 이야기를 써놨는지를 모르겠지만,

첫째. 그렇게 경험이 많다면 오에카키, 싸이월드 그림판,
동양종금이나 몇몇 은행에서 쓰이는 자바기반 보안 말고 크로스 플랫폼이
가능한 자바기술로 구현된것이 뭐가 있는지 예를 들어 보시지요.

우리가 흔하게 접하는 것들중에 말이죠.

만들수 있다는 이야기는 필요없으니 그만두시구요.
현재의 개발자 인력기반과 시장 수요 따위를 고려하지 않는
꿈꾸는 이야기 따위는 어짜피 의미 없습니다.

웹에 대한 개념? 역사? 내가 내 입으로 수업했던 내용이라서 조금은 아는데
그다지 정통성을 내세워서 권위를 세울만한 역사는 없던걸로 기업합니다.
뭐가 그렇게 난 모르고 당신만 아는 대단한 역사가 있었는지 말씀해주시지요.
니따위가 모르니깐 그런 이야기를 하는거야... 라고 말을 했으면
정답을 이야기 해야겠지요.

그렇게 멋지게 표현한 웹이란 뭡니까?

멍청한 것들이 표준도 모르면서 웹을 데탑처럼 꾸밀려고 하네?
그런게 불만이십니까? 데탑의 편리한 방식을 최대한 웹으로 옮기려고 노력하는
MM 의 RIA 계획이나, curl 을 보면 혈압올라 쓰러지겠습니다.
그 이야기가 좀 더 과거로 올라가면,
ftp 로 파일을 전송해야 하고, 메일은 mailto: 프로토콜을 사용해야 하는것이
더 좋고 옳다는 피말리는 말싸움까지 나오게 됩니다.
(90년대로 되돌아가서 그때의 싸움에 참가해보시렵니까?)

편리하다면 데탑 기술을 웹으로 옮기는것이 더 옳습니다.
물론 그 과정에서 현재의 MS 처럼 그 기술을 자기 플랫폼의 독점을 위한
수단으로 사용하는건 옳지 않기 때문에 반대해야 겠지만요.

시장 수요, 인력 기반, 현재 상황이 열악하기 때문에 서서히 전환해나가는것이
옳다. 무조건 사용하지 말라는 말은 무리가 있으니 흘려들어도 된다.
앞으로 점점 더 좋아질거다. 라고 말했는데,
뭐가 그리 발끈해서 사람 퇴근하자마자 짜증 받게 하는 식의 반박을 해놓은겁니까?

댁이 말하는 데탑 기술을 사용하던 사람들이 웹의 특성을 모르면서
어거지로 생각한다는 말... 대충 긍정할 수 있습니다.
뭐 이따위로 기분나쁘게 말 안했으면 충분히 나도 좋게
"그렇죠. 하지만, 지금 상황이 이러니 어쩌겠어요. 좀 더 나아지게 해야죠 ^^"
라는 말 따위는 나도 할 수 있었을겁니다.

여기에서는 거의 rom 상태라서 모르겠지만, 이름을 자주 뵌것 같은데,
모질라에서 활약 많이 한다고 여기 놀러오는 사람들은 병신인줄 압니까?
사람 엿같이 무시하는 그따위 성격 버리십시오.

"세계의 넓은 거미줄" 이 html 만을 위해 존재하는건 아닙니다.
웹에 대한 역사를 이야기 하기 전에
하이퍼 텍스트라는 말이 왜 나왔는지 그 의미부터
먼저 생각해보시죠. 하이퍼텍스트의 의미를 생각하면 충분히
웹에 대해 정의를 내리는게 얼마나 웃긴 이야기인지 알수 있을테니깐요.

바이런 wrote: 첫째. 그렇게 경험이 많다면 오에카키, 싸이월드 그림판,
동양종금이나 몇몇 은행에서 쓰이는 자바기반 보안 말고 크로스 플랫폼이
가능한 자바기술로 구현된것이 뭐가 있는지 예를 들어 보시지요.

우리가 흔하게 접하는 것들중에 말이죠.

만들수 있다는 이야기는 필요없으니 그만두시구요.
현재의 개발자 인력기반과 시장 수요 따위를 고려하지 않는
꿈꾸는 이야기 따위는 어짜피 의미 없습니다.

웹에 대한 개념? 역사? 내가 내 입으로 수업했던 내용이라서 조금은 아는데
그다지 정통성을 내세워서 권위를 세울만한 역사는 없던걸로 기업합니다.
뭐가 그렇게 난 모르고 당신만 아는 대단한 역사가 있었는지 말씀해주시지요.
니따위가 모르니깐 그런 이야기를 하는거야... 라고 말을 했으면
정답을 이야기 해야겠지요.

그렇게 멋지게 표현한 웹이란 뭡니까?

멍청한 것들이 표준도 모르면서 웹을 데탑처럼 꾸밀려고 하네?
그런게 불만이십니까? 데탑의 편리한 방식을 최대한 웹으로 옮기려고 노력하는
MM 의 RIA 계획이나, curl 을 보면 혈압올라 쓰러지겠습니다.
그 이야기가 좀 더 과거로 올라가면,
ftp 로 파일을 전송해야 하고, 메일은 mailto: 프로토콜을 사용해야 하는것이
더 좋고 옳다는 피말리는 말싸움까지 나오게 됩니다.
(90년대로 되돌아가서 그때의 싸움에 참가해보시렵니까?)

편리하다면 데탑 기술을 웹으로 옮기는것이 더 옳습니다.
물론 그 과정에서 현재의 MS 처럼 그 기술을 자기 플랫폼의 독점을 위한
수단으로 사용하는건 옳지 않기 때문에 반대해야 겠지만요.

시장 수요, 인력 기반, 현재 상황이 열악하기 때문에 서서히 전환해나가는것이
옳다. 무조건 사용하지 말라는 말은 무리가 있으니 흘려들어도 된다.
앞으로 점점 더 좋아질거다. 라고 말했는데,
뭐가 그리 발끈해서 사람 퇴근하자마자 짜증 받게 하는 식의 반박을 해놓은겁니까?

댁이 말하는 데탑 기술을 사용하던 사람들이 웹의 특성을 모르면서
어거지로 생각한다는 말... 대충 긍정할 수 있습니다.
뭐 이따위로 기분나쁘게 말 안했으면 충분히 나도 좋게
"그렇죠. 하지만, 지금 상황이 이러니 어쩌겠어요. 좀 더 나아지게 해야죠 ^^"
라는 말 따위는 나도 할 수 있었을겁니다.

여기에서는 거의 rom 상태라서 모르겠지만, 이름을 자주 뵌것 같은데,
모질라에서 활약 많이 한다고 여기 놀러오는 사람들은 병신인줄 압니까?
사람 엿같이 무시하는 그따위 성격 버리십시오.

"세계의 넓은 거미줄" 이 html 만을 위해 존재하는건 아닙니다.
웹에 대한 역사를 이야기 하기 전에
하이퍼 텍스트라는 말이 왜 나왔는지 그 의미부터
먼저 생각해보시죠. 하이퍼텍스트의 의미를 생각하면 충분히
웹에 대해 정의를 내리는게 얼마나 웃긴 이야기인지 알수 있을테니깐요.

1. 예를 들어보죠. 구글 어스나 msn virtual earth는 activex를 쓰지 않고 구현해냈습니다. 이건 어떻게 설명하시겠습니까? 마소는 머리에 총맞아서 activex 안쓰고 버츄얼 어스를 서비스하나요? 국내 포털이라는 녀석들의 지도 서비스를 보면 activex 안깔고는 절대 불가능하게 되어있습니다.

2. 크로스플랫폼 이야기 잘 하셨습니다. 자바 말고 크로스플랫폼 가능한 웹 관련 플랫폼이 현재 뭐가 있는지도 궁금하군요. 플래시 정도? 님은 뭔가 잘 아시는 듯 하니까 알려주세요.
그리고 현재의 개발자 인력기반과 시장 수요 따위 운운하셨는데 눈을 돌려 해외로 바라보시길 바랍니다. 님이 드신 예는 전부 국내에 한정된 것일 뿐입니다. 님같은 분들이 현재 운운하면서 activex에 빠져든 덕분에 마소라는 기업에 대한민국의 웹이 종속된거고 덕분에 국내 시장 철수하네 마네 한마디로 온 나라가 덜덜 떠는겁니다.

3. 팀 버너드 리 경(작위를 받았으니)이 WWW를 만들 때 정신 중 하나가 접근성이었다는 사실, 님이 그걸 가르쳤는지는 모르겠지만 새로운 사실이라면 알아두시는 편이 좋을 듯 싶습니다. 그 따위 정신은 무시해도 된다고 생각하신다면 뭐 어쩔 수 없습니다만.
거미줄 운운 하셨는데 세계의 넓은 거미줄 중 대한민국의 거미줄은 99%가 마소라는 한 회사에 종속되어 있다고 생각합니다.

4. 왜 다음은 activex를 쓰지 않으면 파일 첨부도 못하고 카페 글 수정도 못하게 했나요? activex 없던 시절에는 파일 첨부가 안되고 글 수정조차 못했는데 그게 activex로 가능하게 된겁니까? 해외 유수의 메일 서비스는 activex 없이 파일 첨부와 게시판 글 수정이 안되는 건가요?
님은 activex의 남용에 대해서는 애써 무시하시는 듯 싶습니다.

한가지 wrote: 1. 예를 들어보죠. 구글 어스나 msn virtual earth는 activex를 쓰지 않고 구현해냈습니다. 이건 어떻게 설명하시겠습니까? 마소는 머리에 총맞아서 activex 안쓰고 버츄얼 어스를 서비스하나요? 국내 포털이라는 녀석들의 지도 서비스를 보면 activex 안깔고는 절대 불가능하게 되어있습니다.

2. 크로스플랫폼 이야기 잘 하셨습니다. 자바 말고 크로스플랫폼 가능한 웹 관련 플랫폼이 현재 뭐가 있는지도 궁금하군요. 플래시 정도? 님은 뭔가 잘 아시는 듯 하니까 알려주세요.
그리고 현재의 개발자 인력기반과 시장 수요 따위 운운하셨는데 눈을 돌려 해외로 바라보시길 바랍니다. 님이 드신 예는 전부 국내에 한정된 것일 뿐입니다. 님같은 분들이 현재 운운하면서 activex에 빠져든 덕분에 마소라는 기업에 대한민국의 웹이 종속된거고 덕분에 국내 시장 철수하네 마네 한마디로 온 나라가 덜덜 떠는겁니다.

3. 팀 버너드 리 경(작위를 받았으니)이 WWW를 만들 때 정신 중 하나가 접근성이었다는 사실, 님이 그걸 가르쳤는지는 모르겠지만 새로운 사실이라면 알아두시는 편이 좋을 듯 싶습니다. 그 따위 정신은 무시해도 된다고 생각하신다면 뭐 어쩔 수 없습니다만.
거미줄 운운 하셨는데 세계의 넓은 거미줄 중 대한민국의 거미줄은 99%가 마소라는 한 회사에 종속되어 있다고 생각합니다.

4. 왜 다음은 activex를 쓰지 않으면 파일 첨부도 못하고 카페 글 수정도 못하게 했나요? activex 없던 시절에는 파일 첨부가 안되고 글 수정조차 못했는데 그게 activex로 가능하게 된겁니까? 해외 유수의 메일 서비스는 activex 없이 파일 첨부와 게시판 글 수정이 안되는 건가요?
님은 activex의 남용에 대해서는 애써 무시하시는 듯 싶습니다.

후...

1 . 구글어스는 잠깐밖에 사용안해봤고, 버츄얼 어스는 사용해본적 없습니다.
적어도 잠깐 사용해봐서 정확하진 않지만 구글어스를 봤을때...
그게 지금 화제삼아 이야기했던 웹에 대한것과는 거리가 멀지 않나 싶습니다.
(그건 그냥 어플리케이션 아닙니까?)
그걸 지금 이야기했던 웹과 연결시킬수 있으면 온라인게임도 연결되지
않을까 싶구요. (PS2 의 파이널 판타지11 같은것을 포함해서...)

2 . 지금 우리가 딴나라 이야기 하고 있는게 아니었습니다. 해외로 눈을
돌려서 그 나라들 기준에 맞춰서 생각하자구요?
딴나라 이야기 하면 액티브X 이야기 꺼낼것도 없지 않습니까.
사양화 되어가는지 눈에 안보이는 기술이 되어가고 있으니깐요.

제가 이야기 하고 있던건 분명 현실상 어려움이 있으니깐
천천히 대안을 찾아나가는 동안은 어쩔수 없이 사용할 수 밖에 없을것
같다 였는데... 저기 위에 뭐 "대안 따위가 뭐 필요해! 그냥 쓰던거 써!" 라고
이야기 한 부분 있습니까?

무슨 살다 살다 일본에 조선 팔아넘긴 이완용 같은 놈.
같은 표현은 처음 들어보네요.

2.3.4
MS 신봉자로 몰아가시는 겁니까? 그런 사람이면 이 사이트에 들어와서
이 게시물에 휘말일 일도 없었겠지요. 웹 접근성과 크로스플랫폼 무시하는
사람 아닙니다. (그런 사람이면 당장 별 이득도 없는 여기와서 게시물
뒤적거릴 일도 없구요.)

적대 하겠다 하여 사람을 영 엉뚱한 쪽으로 몰지 말아주시죠.

제 이야기의 주요 요점은 하나였습니다. 당연 바꿔나가야 한다.
하지만, 지금 현실상황을 다 때려부시고 아싸리 새로 시작하자
라는거는 좀 아니다.

뭔가 문제가 있는 의견입니까?
그런건 모잘라! 라는 생각으로 지금 액티브X 쓰는 회사들 직원들
다 일 그만두고 자바 학원 다니라는 생각은 아니시겠지요.
분위기로 봐서는 그렇게 느껴지지만 그렇게 잔혹하진 않을거라 생각합니다.

아니 뭐 시간을 두고 천천히 바꿔가는것이 좋다. 지금도 서서히 변하고
있지 않냐? 자바가 대체 기술이라고는 하는데 아직 사용되는 경우를
많이는 못봤다. 아직 좀 사용층이 빈약한것 같다.
액티브X 대체기반이 부족한 상황에서 무작정 없애자고 하는건 횡포인것
같다. 아직 현실적으로 완전 버리자고 하는건 무리고, 점차 바뀌고 있으니
(그래요 말 그대로 모질라 사용안하던 나도 이렇게 와서 지켜보고 있으니...)
좋은 결과가 있지 않을까 싶다. 그 방안이 마련되는 동안엔 완전 무시는
힘들것 같다...

해석이 필요한겁니까? 제목이 걸작이군요. 말을 함부로 한다라...
내 참... 불여우가 좋아서 관심있는 사이트로 좀 자주 들어오다
의견이 있어서 답글 하나 남겼다가 어디서 굴러먹다 온지도
모르는 개뼉다귀 풋내기가 와서 찌질거린다. 라는듯한 뉘앙스로 병신취급 당했는데
상황 반대로 놓고 봐서 말이 곱게 나갈지 궁금하군요.

이 동네에선 현실적으로 생각해서 전환과정을 천천히 밟아야 한다고
이야기하면 무슨 빨갱이 취급 받는겁니까?


마지막으로... 웹표준이나 크로스 플랫폼이나 합의의 대상이지,
정의의 대상은 아니지 않나 생각합니다.

프로토콜이란걸로 서로 약속해서 인터넷이 연결되었듯이
합의하고, 설득해나가는게 올바른거지. 안지킨다 하여 저놈들 X새끼!
하면서 범법자 취급하는건 옳지 않습니다.

표준이란 법규가 아닌 약속이고, 약속은 신뢰고, 신뢰는 날 적대하지 않는 사람에게
생기는 거지 않습니까. 오늘은 정말 어이없는 한순간의 상황으로 순식간에
MS 옹호자가 되어버렸는데, 지금까지 쭉 글 읽어오면서 좀이라도
"뭐... 그것도 나쁘지 않던데..." 라고 한마디 툭 던진 사람들
MS 옹호자 쓰레기 만드는 분위기에 질려버릴것 같습니다.

좀 흥분하신것 같습니다. 진정 하시구요.
제가 아는건 별로 없지만, 몇가지 답을 달아보자면...

1.
한가지 님께서Google Maps를 Google Earth라고 잘못 말씀하신것 같습니다.
Google Maps는 지도의 확대, 스크롤등을 ActiveX를 쓰지않고 Ajax로 구현해 낸 멋진 작품이죠.
OS 종속적이지 않고, 불여우, 사파리, IE등등을 모두 지원합니다.
(그렇다고 구글이 웹표준을 잘 지키느냐 하면 그것도 아니지만)

2.

바이런 wrote:마지막으로... 웹표준이나 크로스 플랫폼이나 합의의 대상이지,
정의의 대상은 아니지 않나 생각합니다.

물론 정의의 대상은 아닙니다. 개인 홈페이지에서 웹 표준을 지키고 있지 않은걸 억지로 바꿔라 라고 할수는 없는 노릇이죠.
(기업의 고객 입장에서 바꾸라고 요청할 수는 있을 거라고 생각합니다만.)
하지만 적어도 정부기관같은 공공기관의 페이지는 대부분의 브라우저에서 브라우징 할 수 있어야 한다고 생각합니다. 그것을 위해서 따로따로 페이지를 만들기 보다는, 웹 표준을 지킨 페이지 하나를 만들면 여러 브라우저에서 (똑같이는 아니더라도) 브라우징 할 수 있죠.
여러 페이지를 만드는 비용이 코더를 재교육 시키는 것보다 싸게 먹힌다 라고 하면 할 말이 없습니다만, 장기적으로 볼 때 분명 웹표준으로 가는것이 비용도 적게 들고 유지보수면에서 편리하다고 생각합니다.

바이런 wrote: 뭐가 그리 발끈해서 사람 퇴근하자마자 짜증 받게 하는 식의 반박을 해놓은겁니까?

발끈하지 않았습니다. 하지만, 님을 매우 기분 나쁘게 했으니 사과 드립니다. 제가 다시 읽어 보니 기분이 매우 나쁘게 읽힐만도 합니다. 사실은 아래에 써 놓은 제가 쓴 글에 대한 주소 하나만 올리려고 했는데(eouia님이 매우 잘 정리해 주시기도 하셨으므로), 그 글을 쓰던 때에는 검색해도 이상하게 잘 안 걸리더군요. 그래서, 대신 몇 자 적은 게 님의 기분을 상하게 했군요. 이에 대해 다시 사과 드립니다.

첫째. 그렇게 경험이 많다면 오에카키, 싸이월드 그림판,
동양종금이나 몇몇 은행에서 쓰이는 자바기반 보안 말고 크로스 플랫폼이
가능한 자바기술로 구현된것이 뭐가 있는지 예를 들어 보시지요.

자바 애플릿이 쓰이는 곳을 정말 모르신다는 말입니까? 어째서, 한국에만 한정하시나요? 물론, 썬은 장사(?)를 잘못해서 자바의 잠재력을 (한국의) 웹 클라이언트 시장에서 충분히 활용하지 못 했습니다. 하지만, 님이 눈을 조금만 바깥으로 돌리면 ActiveX를 쓰지 않고도 얼마든지 훌륭한 UI를 지닌 - 데스크탑 못지 않은- 곳을 발견할 수 있습니다. 한국의 대부분의 웹 기반 교육 시스템은 ActiveX가 있어야만 돌아가지만, flash 혹은 Java를 써서 그들이 지원하는 주요 플랫폼에서 별 문제 없이 쓸 수 있는 온라인 교육 시스템은 여러 개 있습니다. 또, 얼마 전에 접한 웹 브라우저에서 돌아가는 화상 및 음성 회의 시스템은 플래시로 쓰인 것인데(매크로미디어에서 만들었으니 당연하다?), 리눅스에서도 아무 문제 없이 파일 교환, 화이트보드 공유, 화면 공유, 음성 및 화상 채팅 등이 가능하더군요. 메이저리그에서 운영하는 http://www.mlb.com에서 제공하는 각종 야구 동영상은 파이어폭스로도 아무 문제 없이 볼 수 있습니다. 왜 MBC나 SBS의 동영상은 그렇게 못 보지요 (소스를 보고, URL을 알아내는 노력을 하지 않고서는)? (KBS는 최소한 노력은 하고 있습니다. 약간 코드를 잘못 짜 놓아서 아직 못 보지만, 약간만 손보면 됩니다)

님이 흔히 접하는 수많은 한국의 ActiveX 가운데 정말 필요한 것이 얼마나 있고, 다른 것으로 대체 불가능한 것이 얼마나 있으며, 더 좋은 UI나 화려함을 위해(ActiveX를 쓰면 항상 좋은 UI가 나온다는 명제도 사실 참이 아니지요. 네이버 등에서 제공하는 지도서비스와 MapQuest, 미국 야후, Google 등에서 제공하는 지도 서비스 가운데 어느 것이 더 편한지 비교해 보세요. Google은 최근에 나온 AJAX를 썼으니, 논외로 한다고 해도 MapQuest 등은 1990년대 중반부터 서비스를 제공했습니다.) ActiveX를 쓰면서 'graceful degradation'을 제공해 줄 수 없는 경우가 얼마나 될까요? 왜 MS조차도 ActiveX(DCOM)를 그다지 앞에 내세우지 않을까요?

만들수 있다는 이야기는 필요없으니 그만두시구요.
현재의 개발자 인력기반과 시장 수요 따위를 고려하지 않는
꿈꾸는 이야기 따위는 어짜피 의미 없습니다.

어떻게 할까요? 가만히 있을까요? 님을 매우 기분 나쁘게 한 단락은 사실 님에 대한 것이라기 보다는 웹에 대한 개념 정립도 안 된 채로 웹 개발자라고 하면서 자신이 알고 있는 Windows API들을 - 웹 고유의 동등한 방법이 있는지에 대한 고민도 없이 - 손쉽다는 이유만으로 웹에 마구잡이로 쓰는 많은 이들을 대상으로 한 것이었습니다. 물론, 그런 문제는 순전히 그들만의 잘못은 아닙니다. 님이 언급한 인력 수급 구조, 개발자 교육, 시장 조건, 한국 인터넷과 웹의 성장 과정 등 여러 가지 요소가 결합해 나타난 결과입니다. 그러므로, 그냥 가만히 손놓고 있어야 합니까? 꿈꾸는 이야기는 하지 말라고요? 꿈꾸는 얘기가 아니라 지금 당장 현실에서 제가 불편하거든요. 그래서, 한 마디라도 해서 조금아니마 고쳐 놓아야 제가 좀더 편하거든요. 그래서, 때로는 님 같은 분의 심기를 건드리는 교양 없는 얘기도 합니다.

웹에 대한 개념? 역사? 내가 내 입으로 수업했던 내용이라서 조금은 아는데
그다지 정통성을 내세워서 권위를 세울만한 역사는 없던걸로 기업합니다.
뭐가 그렇게 난 모르고 당신만 아는 대단한 역사가 있었는지 말씀해주시지요.
니따위가 모르니깐 그런 이야기를 하는거야... 라고 말을 했으면
정답을 이야기 해야겠지요.

대단한 역사, 정통성, 권위? 이런 단어의 의미를 잘 모르겠군요. 웹을 누가 만들었고, 왜 만들었는지 - 수업도 하셨다니 - 잘 아시리라고 보는데, 아닌가요? 하이퍼텍스트의 개념부터 얘기하자면 물론 더 많이 거슬러 올라가야겠지만, 현재 우리가 알고 있는 웹의 창시자는 팀 버너스 리라고 해도 과히 틀리지 않겠지요? 몇 번이나 한 얘기를 되풀이할 수 없으니 2년 쯤 전에 여기에 쓴 글에 대한 URL을 드립니다. 대단한 역사, 정통성, 권위는 없을지 몰라도 그가 웹을 만든 중요한 목적이 이기종 컴퓨터 사용자끼리의 정보 교환 및 공유라는 사실은 변하지 않습니다.

viewtopic.php?t=485

(거기에서 그냥 ssl을 써서 금융 거래를 하면 될 것을 왜 ActiveX를 쓰는지 모르겠다는 말은 '공인 인증서 도입' 배경을 몰랐기 때문에 쓴 말입니다. 물론, 공인 인증서를 쓴다고 해서 ActiveX를 써야 할 이유는 없습니다. 그 도입 초기인 1998년 무렵에 netscape용 플러그인도 같이 보급되었다는 사실이 이를 증명하고요.)

다음 강연 내용도 보시고요. 팀 버너스 리가 재작년 가을에 영국 왕립 학회에서 한 웹의 과거, 현재, 미래에 대한 강연입니다.

http://www.royalsoc.ac.uk/page.asp?id=3110

멍청한 것들이 표준도 모르면서 웹을 데탑처럼 꾸밀려고 하네?
그런게 불만이십니까? 데탑의 편리한 방식을 최대한 웹으로 옮기려고 노력하는
MM 의 RIA 계획이나, curl 을 보면 혈압올라 쓰러지겠습니다.
그 이야기가 좀 더 과거로 올라가면,

그래서, Xform도 만들고, WHATWG 등의 노력도 합니다. AJAX 같은 것도 쓰고요. 데스크탑의 편리함(편리하고 좋은 점만 옮겨야지, 그렇지 않은 점도 같이 옮기면 안 되겠지요)을 옮겨 놓는 것은 당연히 좋은 일입니다. 그런 노력에는 아무런 잘못도 없습니다. 하지만, 그렇게 하는 과정에서 플랫폼 종속적인 기술을 마구잡이로 쓰는데에 문제가 있는 것입니다. 그 오용과 남용의 정도가 이루 말할 수 없어서, 전혀 쓸 필요가 없는 - 10년 된 플랫폼 및 장치 독립적인 기술로도 충분히 구현 가능한 것을 그에 대한 검토도 없이 - 곳에 쓰거나, 그 기술을 써서 얻을 수 있는 잇점이 미미한 곳에도 쓰거나, 그 기술 적용 결과물이 그렇지 않은 다른 구현보다 더 못 한 경우가 허다하니 문제이지요. 웹의 탄생 과정에서 가장 중요한 목표 중 하나가 이기종 간의 자유로운 정보 교환이었음을 인식한다면 플랫폼 종속적인 기술과 상대적으로 독립적인 기술이 있을 때 어느 것을 골라야 하는지는 자명합니다. 물론, 다른 요소도 많이 - 위에서 님도 언급했고, 저도 언급했고, 2년 전에 제가 쓴 글에서도 언급했듯이- 있습니다. 그에 대해서는 2년 전 제 글에서 언급했으니 (그 주소도 드렸으니까) 여기서는 약합니다.

ftp 로 파일을 전송해야 하고, 메일은 mailto: 프로토콜을 사용해야 하는것이
더 좋고 옳다는 피말리는 말싸움까지 나오게 됩니다.
(90년대로 되돌아가서 그때의 싸움에 참가해보시렵니까?)

무슨 싸움을 말씀하시는지, 저는 전혀 감도 안 옵니다. mail 전달은 그때나 지금이나 smtp로 하지요. 파일 전송은 지금도 ftp/http/smpt/기타 여러 방법으로 하고요. ftp는 anonymous인 경우에만요. (뭐, 아직도 로그인하는 경우에도 ftp를 쓰고, telnet을 쓰는 사람들도 있기는 하더군요.)

시장 수요, 인력 기반, 현재 상황이 열악하기 때문에 서서히 전환해나가는것이
옳다. 무조건 사용하지 말라는 말은 무리가 있으니 흘려들어도 된다.
앞으로 점점 더 좋아질거다. 라고 말했는데,

저는 그다지 무리가 있다고 여기지 않습니다. 다른 분도 적었듯이 대부분의 경우 ActiveX를 써야 할 절대절명의 이유가 있는 곳이 별로 없습니다. 굉장히 빠른 속도와 그래픽 하드웨어를 직접(?) 제어해야 하는 게임(게임도 게임 나름입니다) 정도를 제외하고는요. ActiveX를 꼭 써야 할 곳이 많다면, 그에 대한 대안이 Java (signed) applet 정도이므로 'Java 개발자 구하기기 함들다', '그들은 너무 많은 급료를 요구한다'와 같은 얘기가 나오겠지만, 꼭 써야만 할 곳이 별로 없습니다. 두어 번 적었지만, ActiveX를 써서 만들어 낸 결과물이 그다지 편리하지도 않고요. eouia님이 쓰신 대로 조금 더 편리하다고 해도 사용자들이 그런 편리성을 얼마나 높게 쳐 주는지도 의문이고요. 플랫폼 종속적인 기술을 사용해서 얻는 잇점이 잠재적인 사용자/고객을 잃어서 입는 손실보다 작다면 그 사이트 입장에서도 손해겠지요. 뭐, 한국에서만 장사할 것이라면 ... 알아서 하라고 하세요. 하지만, 공공 기관은 다른 얘기입니다. 전자 정부 사이트 등에서 ActiveX를 쓰는 것은 절대 용납할 수 없습니다.

"세계의 넓은 거미줄" 이 html 만을 위해 존재하는건 아닙니다.
웹에 대한 역사를 이야기 하기 전에
하이퍼 텍스트라는 말이 왜 나왔는지 그 의미부터
먼저 생각해보시죠. 하이퍼텍스트의 의미를 생각하면 충분히
웹에 대해 정의를 내리는게 얼마나 웃긴 이야기인지 알수 있을테니깐요.

이에 대한 답도 2년 전 제 글로 대신합니다.

바이런 wrote:표준이란 법규가 아닌 약속이고, 약속은 신뢰고, 신뢰는 날 적대하지 않는 사람에게
생기는 거지 않습니까. 오늘은 정말 어이없는 한순간의 상황으로 순식간에
MS 옹호자가 되어버렸는데, 지금까지 쭉 글 읽어오면서 좀이라도
"뭐... 그것도 나쁘지 않던데..." 라고 한마디 툭 던진 사람들
MS 옹호자 쓰레기 만드는 분위기에 질려버릴것 같습니다.

우선 포럼의 게시판이라는 것이 글 안에 사람의 감정과 느낌을 제대로 표현 할 수 없다는 것을 전제로 생각하시구요...

지금 쓰레드를 쭉 흩어 보면 바이런님을 MS 옹호자라고 이야기하지도 않았고 단지 반대 의견을 피력한 사람들이 좀 많은 것 뿐인데 분위기가 그렇다고 하시는 건 좀 아닌것 같습니다. (물론 한가지님의 이야기는 논란의 여지가 있습니다만...) 그럼 자바를 대안으로 제시한 사람은 Sun의 옹호자인가요?

플러그인이 그야 말로 웹을 도와야지 웹을 대체해서는 안된다고 봅니다. 잘 아시겠지만 웹의 발전과 진화는 상호 운용성이 전제되어야만 가능합니다. 플러그인이 브라우저 상호 운용성을 해치게 되면 그건 엄밀히 말해 웹은 아니라고 생각됩니다.

신정식님이 좀 강하게 ActiveX 쓰는 걸 뭐라 하느냐 하면 우리 나라 밖에는 이렇게 까지 웹을 훼손해가며 쓰는 나라가 없기 때문이기 때문입니다. 제가 베리사인과 2년전에 같이 일한적 있는데 우리 나라 코드 사인 인증서 판매량이 전 세계의 90%입니다. 미국에도 아주 유명한 몇개 IT기업밖에 사용하지 않습니다. 물론 그 사람들은 자바 Plugin도 같이 사용합니다. (자바 코드사인 인증서도 있습니다.) ActiveX 많이 쓰는 우리 나라가 선진적인 웹 국가는 아니라는 거죠...

저도 ActiveX 쓰는 걸 당장 바꿀 수는 없고 대안이 필요하다고 생각됩니다. 그렇다고 파이어폭스에서 제공하는 XPCOM이 대안이 될 수도 없습니다. 물론 Win/Mac/Linux에 다 돌긴 하지만 그래도 브라우저 종속 기술 아닙니까? Java, 물론 이것도 완벽한 대안이 될 수는 없습니다. Flash, Ajax 마찬가지입니다.

중요한 건 플러그인이 웹을 대체하려고 할때 이미 그건 웹이 아니라는 사실입니다. 따라서 웹 개발자들이 어떻게 하면 피할 것이가 피한다면 얼마나 OS/브라우저 종속성을 낮출 기술을 사용할 것인가?를 판단해서 사용해야 된다는 것이죠. 그 사람들은 어플 개발자가 아니라 웹 개발자니까요. 늦었지만 이제 W3C가 Rich Web Application W/G 두개를 어제 발족 시켰습니다.

http://www.w3.org/News/2005#item162
http://channy.creation.net/blog/?p=203

p.s. 저는 Windows Live 같은 대안 기술도 바람직해 보입니다. 이제 MS가 ActiveX같은 건 안 만들거라는 확신이 듭니다만...

바이런 wrote:액티브 X 가 윈도우에서만 돌아가거나 표준화가 안된다거나
하는걸 이야기 하고자 하는게 아니라,

그렇게 쓰지 말라고 이야기를 한다면 그걸 대체할 기술이 뭐냐 라고
묻는것 같은데요?
(몰라서 물어보는게 아니라 아는데 안쓰면 대책은 뭐냐 라는거겠죠...)

그건 대체적인 웹제작자들의 의문점이 아닐까 싶기도 합니다.
액티브 X 를 안쓰고 다른 기술로 액티브 X 만큼 제작이 쉽고,
다양한 기능을 탑재한채로, 더불어 크로스 플랫폼 까지 완벽하게
지원되는게 있을까의 의문이요...

대책이 자바라고는 하지만...
ㅡ ㅡ 자바로 만들어진거라고는 아직 오에카키 빼고는 본적이 없는것 같구요.

java applet 유용하게 쓰이는 곳들 꽤 많습니다 우리나라에서 별로 안쓰는 것 뿐이죠... (외국쪽 대학 수업 자료들 보면 애플릿으로 그래피컬하게 동작을 보여주는 것들이 자주 제공되더군요)

activeX 에서 할 수 있는 건 mozilla plugin 에서도 할 수 있지 않나요? mplayerplug-in 에서 mplayer 를 실행시키던데... 내가 짠 프로그램 설치해서 실행시키는 것도 안될 이윤 없어보이는군요... 다만 os 나 아키텍쳐에 따라 플러그인이 따로따로 작성해야할 필요가 있겠군요...

현재 그 자랑스런 activeX 조차도 64bit I.E 용으로는 제공이 안되서 사용못하는 경우가 허다하던데... activeX 로 도배를 해서 구축된 곳들 중에서 정말 그렇게 해야할 필요가 있겠냐 싶은 곳은 그리 많지 않더군요...

그리고 꼭 필요하다면 그걸 쓰는 것까지는 뭐라고 하고 싶지 않습니다만 적어도 돌아갈 방법정도는 제공해야 하지 않을까 합니다...

데스크탑에서 쓰던데로 DnD 를 통해 파일을 업로드하고 WYSIWYG 으로 글을 올리는 건 좋습니다만 만약 그런 기능을 사용할 수 없는 경우라도 파일을 업로드하고 글을 쓰는데 지장이 있진 않도록 작은 배려를 해줬으면 지금처럼 불만에 가득차 있지는 않을 듯 싶네요

참고로 VOD 제공이라던가 음원 제공 같은 경우에도 DRM 등을 이용해 제한된 접근을 허용한다기 보다 activeX 를 통해 주소를 숨기고 접근할 방법을 차단하려고 하기 때문에 activeX 남용이 되버린게 아닐까 싶은데요...



p.s) activeX 가 정말 꼭 필요하다는 단정을 하시는 듯 싶군요... activeX 가 그렇게 훌륭한 기술이라면 win32 api 에는 통달하고 있을 ms 에서 자신의 웹사이트에 왜 activeX 를 "전혀" 사용하지 않았는지 의문이군요 :p

정태영 wrote:p.s) activeX 가 정말 꼭 필요하다는 단정을 하시는 듯 싶군요... activeX 가 그렇게 훌륭한 기술이라면 win32 api 에는 통달하고 있을 ms 에서 자신의 웹사이트에 왜 activeX 를 "전혀" 사용하지 않았는지 의문이군요 :p

바이런님의 글 요지를 보면 꼭 그렇지 않습니다. 지금 모든 걸 바꿀 수 있겠느냐. 천천히 바꾸도록 대안을 제시하자라는 말씀이십니다. 저도 이 말씀엔 동감입니다. 동감^^

그러나 이걸 바꾸려면 무엇보다도 빛알갱이님이 말씀 하신 웹에 대한 근본적인 성찰이 웹 개발자(기획, 디자이너)들에게 있어야 합니다. 왜 디자이너, 기획자, 개발자 앞에 웹이 붙는지 말이죠.

웹의 목적은 변한지 이미 오랩니다.

접근성 따지고 정보의 전달 따지면 그냥 telnet 쓰십시오. 웹은 이제 어플리케이션입니다.

ActiveX를 다른것으로 대체한다고 하는데 대체 했다고 치고 그로 인해 매출이 1%라도 감소한다면 어떻게 하겠습니까? 그렇더라도 웹의 목적(그것도 수십년전의 목적)에 맞추기 위해 감수하시겠습니까? ActiveX를 써서 게임을 자동으로 실행시켜주면 게임 접속률이 1% 오른다고 할때 어떻게 하시곘습니까?

Failback을 마련한다. 마련해줄태니 개발비 50%더달라 또는 오픈일을 몇달 연장하자고 하면 어떻게 하시겠습니까?

이제부터라도 표준을 지키자. HTML표준 말고라도 프로그래머가 따르면 좋을 표준은 산더미입니다. 그나마 HTML표준은 프로그래머가 지키고자 해도 지킬 수 없을 뿐더러 HTML표준은 늘 뒤따라가는 표준입니다. 말많은 MS만의 HTML표준들 언제까지나 MS만의 기술일까요. MS의 DHTML을 보면 Collection의 개념과 ActiveX Document개념이 많이 들어있습니다. 페이지 전체를 하나의 객체로 보는거죠. 반면 W3C는 비유하자면 클래스정도로 보고 있습니다. HTML내의 태그들은 클래스의 멤버가 아니라 단지 데이타일 뿐이죠. 그래서 getElementsByName같은 함수통해서 데이타에서 검색을 하는 형태가 되버리는겁니다.

W3C표준 늦어도 너무 늦습니다. 스타일 시트도 마찬가집니다. 가장 최신의 표준에서야 단어중간에서 줄나누는 워드랩 스타일을 정의했습니다. 모서리 둥근 테이블 등등...
파일 업로드도 일반 POST일때와 뒤에서 처리하는게 천지차이로 틀리다는거 아실겁니다. W3C가 표준만 제시해줬어도 벤더들은 알아서 멋지게 만들었을겁니다. 이제서야 XFORM인가 뭔가 새로운 표준을 만드는것 같던데 살펴보니 필요한건 안만들고 또 옆길로(XML로) 샜더군요. 멀티선택업로드라던가, 업로드 상태표시, 쉬운 파라미터 처리등을 기대했다면 아직 10년은 더기다려야할겁니다.

가려운데를 긁어주지 못하는 W3C를 믿고 기다리느니 비록 표준엔 없지만 ActiveX건 AJAX건 Applet이건 구현하는게 우선아닐까요.

은행권에서 쓰는 ActiveX도 물론 SSL을 쓰게 바꾸면 없앨 수 있습니다. 혹은 SSL이 SEED를 지원하거나. 그러니 모두 손놓고 몇년 기다렸다 사이트 오픈하나요?

구글도 자주 예로 인용되는데 어떤 웹정신이 투철한 프로그래머가 있어서 알아서 ActiveX피해서 안쓰고 만들었을까요? 아니죠. 단지 요구사항이 그랬을겁니다. 구글의 경우는 ActiveX를 쓰는게 오히려 매출이 1%라도 줄어들기 때문이겠죠.

두서없이 써봤습니다. 일단 이만.

YGM wrote:웹의 목적은 변한지 이미 오랩니다.

접근성 따지고 정보의 전달 따지면 그냥 telnet 쓰십시오. 웹은 이제 어플리케이션입니다.

과연 그런지 아닌지는 10년 뒤에 봅시다 두 가지 측면이 상호 배제하는 것이 아니라 충분히 병존할 수 있습니다.

ActiveX를 다른것으로 대체한다고 하는데 대체 했다고 치고 그로 인해 매출이 1%라도 감소한다면 어떻게 하겠습니까? 그렇더라도 웹의 목적(그것도 수십년전의 목적)에 맞추기 위해 감수하시겠습니까? ActiveX를 써서 게임을 자동으로 실행시켜주면 게임 접속률이 1% 오른다고 할때 어떻게 하시ㅤㄱㅖㅆ습니까?

30% 주는 분야도 있고, 15% 느는 분야도 있겠지요. 일률적으로 준다거나 는다거나 얘기할 수 없습니다. 비용도 마찬가지고요. 어떤 시장을 대상으로 하느냐, 어떤 인력 자원을 가지고 있느냐 목표가 단기적이냐 장기적이냐 등에 따라 많은 상황이 있을 수 있습니다. 보기로 든 게임은 지금 논의에 그다지 적합한 보기가 아니라 아주 극단적인 경우입니다.

그나마 HTML표준은 프로그래머가 지키고자 해도 지킬 수 없을 뿐더러 HTML표준은 늘 뒤따라가는 표준입니다. 말많은 MS만의 HTML표준들 언제까지나 MS만의 기술일까요. MS의 DHTML을 보면 Collection의 개념과 ActiveX Document개념이 많이 들어있습니다. 페이지 전체를 하나의 객체로 보는거죠. 반면 W3C는 비유하자면 클래스정도로 보고 있습니다. HTML내의 태그들은 클래스의 멤버가 아니라 단지 데이타일 뿐이죠. 그래서 getElementsByName같은 함수통해서 데이타에서 검색을 하는 형태가 되버리는겁니다.

MS DHML이 뭘 말하는 것인지 잘 모르겠지만.... MSDOM과 W3C DOM 가운데 어느 게 더 명료하고 깨끗한지는 누구한테 물어 봐도 답이 같을 텐데요. (님만 빼고??)

W3C표준 늦어도 너무 늦습니다. 스타일 시트도 마찬가집니다. 가장 최신의 표준에서야 단어중간에서 줄나누는 워드랩 스타일을 정의했습니다. 모서리 둥근 테이블 등등...

늦게 가는 측면이 많이 있습니다. WHATWG에 모인 측에서 WHATWG 결성 전에 웹 응용 프로그램을 위한 표준을 마련하자고 했을 때 만들지 않더니, WHATWG의 활동이 한참 진행된 다음에 이제서야 관련 WG를 두 개 만들었습니다. XBL, XUL, XAML 등에 대한 대응도 늦은 감이 있고요. 흔히 쓰는 window.*에 대한 것도 표준에서 규정하지 않은 채로 두었다가 이제서야 논의를 시작했고요.

하지만, CSS에 대해서는 님과 생각이 다릅니다. 님이 보기로 제시한 보기는 지극히 지엽적인 문제입니다. 사실, 한국이나 일본에서 그런 식의 줄바꿈을 하기는 하지만, 그런 것이 있어도 제가 디자이너라면 절대 안 씁니다. 도대체, 라틴 단어를 하이프네이션도 없이 중간에서 자른다는 게 말이 안 됩니다. (국제 학술 대회에 나가서 발표할 슬라이드에서 영어 단어를 중간에서 마구 잘라 놓는 '만행'을 저지르는 사람들이 가끔 있지요). CSS 1과 CSS 2가 나온 날짜를 한번 보시지요. CSS3는 지금 계속 만들고 있는 중이지만요. 여기서 뒤쳐진 것은 표준이 아니라 주요 브라우저 (특히 MS IE)입니다.

파일 업로드도 일반 POST일때와 뒤에서 처리하는게 천지차이로 틀리다는거 아실겁니다. W3C가 표준만 제시해줬어도 벤더들은 알아서 멋지게 만들었을겁니다. 이제서야 XFORM인가 뭔가 새로운 표준을 만드는것 같던데 살펴보니 필요한건 안만들고 또 옆길로(XML로) 샜더군요. 멀티선택업로드라던가, 업로드 상태표시, 쉬운 파라미터 처리등을 기대했다면 아직 10년은 더기다려야할겁니다.

XFORM 1.1은 지금 만들고 있지만, XFORM 1.0은 2003년에 나왔습니다. 지나치게 복잡해서 구현이 힘들다 어쩐다 말이 많은 것은 사실입니다. 파이어폭스에서는 IBM에서 기여한 코드를 써서 현재 상당 부분 구현되어 있습니다. (기본으로 들어 있지 않지만).

님이 위 단락에서 제시한 문제점에 동의하는 사람들이 만든 것이 WHATWG입니다. 그들의 활동이 엊그제 발족한 Rich Appl. 관련 WG의 활동과 잘 합쳐지면 (WHATWG는 이미 님이 얘기한 이슈들을 모두 다 다루고 있는 '안'을 내놓았습니다) 10년까지는 안 기다려도 될 것 같군요. 어쨌든, 이 부분에서 W3C가 매우 빨리 움직일 필요가 있음에는 의문의 여지가 없습니다.

파일 업로드에 대해서는 정태영님이나 eo* (아이디가 너무 어려워요 )님이 말씀하신 대로 'DnD의 편의성을 얼마나 원하느냐'에 대해 사용자들에게 물어 봤습니까? 편하기는 편하니까 원한다고 칩시다. 그런데, 그런 편리함을 주기 위해 ActiveX를 쓰는데 드는 비용에 비해서 고전적인 form을 통해 업로드하는 fallback을 만드는데 드는 비용이 님이 말한대로 50%나 됩니까? 그것 하나 더하느라고 몇 달간 개장 일자를 늦춰야 합니까? ActiveX를 써서 만든 편리한 편집기에 더해서 그냥 간단한 textarea 하나 더하는데 비용이 얼마나 듭니까? (편집기의 경우에는 javascript만으로 구현해 놓은 크로스브라우저 라이브러리를 가져다 쓰면 아예 ActiveX를 피할 수도 있겠지요) ActiveX를 써서 보여주는 동영상 옆에다가 그 동영상을 직접 볼 수 있는 주소 하나 더하고 링크 걸어 주는 비용이 얼마나 드나요? 청와대 웹 사이트에 가 보세요. 그렇게 하거든요.

철도공사의 표 예약 시스템은 결제만 빼고 리눅스나 맥에서도 아무 불편 없이 쓸 수 있습니다. 그런데, 결제를 - 공인 인증서를 쓰는 것도 아닙니다- 할 때에는 ActiveX를 씁니다. 이런 경우에는 그냥 하던 버릇 때문에 ActiveX를 썼다고 생각이 들 정도입니다. SSL을 못 쓸 이유가 전혀 없습니다. 황당하게도 사용자 로그인은 그냥 http로 합니다 (파이어폭스 등에서도 되니까, 은행 사이트처럼 http를 쓰되 SEED로 암호화해서 하는 게 아닙니다.) 이런 황당한 곳이 비 금융 기관 웹 사이트 가운데 꽤 많습니다. 이런 경우에는 비용 비교는 SSL를 쓰도록 웹 써버 설정하는 비용과 ActiveX 모듈 개발 비용이겠지요. 어느 게 더 들까요? 후자가 덜 들 가능성도 배제하지 못 합니다. 하지만, 설령 그렇다고 해도 그 차이는 미미할 것이며, 그 비용 차이가 '공공 써비스'를 제공하는 기관에서 특정 브라우저와 OS만을 쓸 수 있게 한 것을 정당화할 수 없습니다. e-ticket은 - 외국에서는 비행기 표도 그냥 웹 페이지에 나온 영수증을 아무 프린터로나 출력해서 들고 공항에 가면 내 주는데. 물론 신분증도 보여 주어야 하지만. 그보다 훨씬 싼 기차표 하나 찍는데, 웬 호들갑을 그렇게 떨어야 하는지 잘 모르겠지만 - '위조'를 막기 위해 시스템의 프린터를 직접 제어해야 한다고 하니까 - 이게 또 왜 PDF 등으로 안 되는지 잘 모르겠지만... 그럴만한 이유가 있다고 칩시다- 그 부분에서 ActiveX를 쓰는 것은 불가피한 면이 있다고 할 수 있습니다. 하지만, 결제하는데 ActiveX를 써야 할 이유는 없어 보입니다.

더 황당한 경우도 있지요. 별 것도 아닌 사이트에 로그인*만*하는데 ActiveX를 쓴 경우입니다. 웹 서버에 SSL 설정하는 것도 정말 그런 ActiveX 모듈 만드는 게 싼 가 봅니다.

은행권에서 쓰는 ActiveX도 물론 SSL을 쓰게 바꾸면 없앨 수 있습니다. 혹은 SSL이 SEED를 지원하거나. 그러니 모두 손놓고 몇년 기다렸다 사이트 오픈하나요?

불행히도 SSL로 바꿀 수는 없습니다. 하지만, SEED와 공인 인증서를 구현하는 유일한 방법이 ActiveX는 아닙니다. 이미 1990년대 후반에 넷스케이프용 플러그인이 배포되어서 쓰였고, 또 최근에 다시 두 개의 대표적인 보안 모듈 업체에서 ActiveX를 쓰지 않는 해법을 내놓았습니다.

YGM님의 글을 감히 반박할 수는 없네요. 사실 저역시 비슷한 입장이긴 합니다.
일전에 회사에서 만들었던 서비스는,
"웹상에서 동작하는 드림위버/포토샵 비스므리한 것"이었습니다. 소위 말하는 RIA였죠.

도저히.. 크로스브라우징이 가능하게 만들 수 없었습니다. 그래서 IE 전용으로 만들었습니다. 그나마 Flash, ActiveX 안쓰고 JavaScript로만 만들었습니다. 갖은 닭짓을 다 해봤지만 FF에서 돌아가질 않았습니다. OS 종속적인, 브라우저 종속적인 기법들이 쓰였기 때문에 당연한 것이죠.

그래서
http://css.macple.com/forum/showthread.php?t=126
이런 고민도 했었죠.


지금의 저는 분리된 입장입니다.
1) OS종속적, 브라우저 종속적인 기능이 반드시 필요하다면, 사용한다. 다른 브라우저로 접속하면 안된다는 메시지 정도만 출력해준다. -> 이건 비용이 많이 드는 작업은 아니니까요.
2) OS종속적, 브라우저 종속적인 기능이 반드시 필요한 건 아니라면, 사용하지 않는다. 대신 범용적인 방법을 이용한다.
3) OS종속적, 브라우저 종속적인 기능이 필요없다면 일부러 집어넣지는 않는다.

이정도입니다.

경제논리는 저같은 말단 개발자가 생각할 필요는 없을 것 같습니다. 비 IE 사용자가 전체 이용자의 몇 %가 되어야만 표준화를 따랐을 때의 수익이 IE전용에서의 수익을 넘을 수 있는가 하는 건 기획자나 경영자가 판단할 문제이고, 소위 말해 "당이 결심하면 우리는 따른다"가 되겠죠.

그러므로 경제논리를 이 문제에 들이대는 건 별 의미없는 것 같습니다. 이건 의지의 문제죠. 물론 그 의지라는 게 대부분 돈앞에 휘청거리기 쉽습니다만. 그렇다고 해서 돈안되니까 안한다는 건 위험한 단정이죠. 결국, 돈만 된다면 하겠다는 소리나 같지 않나요? 만의 하나 세상이 뒤집혀 Mozilla가 대세가 되는 날이 온다면, 또 그 때는 모두 ActiveX대신 XUL 프로그래밍으로 전부 바꾸어야 하겠죠. 사용자도 혼란스럽고, 개발자도 혼란스럽습니다. 그걸 막자는게 웹표준화입니다. 안티IE도, 안티ActiveX도 아니라요. 자꾸 그런 쪽으로 몰고 가시면 이야기는 계속 헛돌 뿐입니다.

게다가 세상에는 돈이 안되도 억지로 해야만 하는 경우도 있습니다. 그래서 나온게 미국의 재활법 501조 지요. 경제논리대로라면 미국의 재활법 501조야말로 아우토반역질주겠습니다만, 그렇게 경제논리만 따지면 소외되는 계층 들이 있기 때문에 법으로 강제하는 것입니다. 조만간 한국에도 비슷한 입법이 될 듯도 한데, 아마 그럼 "기업하기 힘든 세상"이라는 소리나 나올까요.

웹표준은 느립니다. 진짜 빌어먹을만큼 느리죠. 발표도 느리지만, 업체에서의 반영도 또 빌어먹게 느립니다.
그러나 표준은 표준입니다. KS표준이 있는 이유도, ISO가 있는 이유도. 다 없는 것보다는 있는 쪽이 낫기 때문입니다. 웹표준도 마찬가지입니다. 그러니까, 할 일 없어서 W3C가 모여서 쑥덕쑥덕하고 있는 건 아니란 말이죠.

IE DOM과 W3C DOM, 어느 쪽이 나은지는 취향일 수도 있겠습니다만, 그렇게 IE DOM의 개념이 훌륭하다면 다른 브라우저/인터넷 업체들은 안티 IE라서 일부러 구닥다리 W3C DOM을 쓸까요? 저로서는 멤버간의 위계도 모호한 IE DOM쪽 보다는 W3C쪽이 좀더 OO적이라고 보는데 말이죠. 어쨌거나 MS 역시 W3C의 멤버이니만큼 그렇게 훌륭한 개념이라면 타 업체들 설득해서 표준제정하는데 별 문제는 없을테지요.

웹이 변했다고 하셨는데 맞긴 합니다.
웹 2.0이 비즈니스적 수사에 불과할 지는 몰라도, 확실히 바뀌고 있습니다. 그러나 그 변화의 바탕이 IE 전용이나 ActiveX에의 의존은 아니라고 봅니다. 해외 웹2.0관련 정보들이나 시멘틱웹 관련 논의들을 보자면, 그 중심 어디에도 IE전용/ActiveX같은 이야기는 없습니다. 브라우저/OS/머신이라는 특정플랫폼에서 탈피하여 WWW자체가 플랫폼이 되는 차세대 이야기들에 그러한 지엽적인(?)이야기는 끼어들 틈 조차 없지요. 오히려 옆길이라고 말씀하신 XForm같은 XML 기술들이 그 대화들의 중심에 서 있죠. 세상이 어디로 향할지는 더 두고봐야겠습니다만, 저로서는 이쪽이 더 "돈되는" 방향이라고 판단하고 있습니다.

많은 좋은 얘기 생략....

eouia wrote:
게다가 세상에는 돈이 안되도 억지로 해야만 하는 경우도 있습니다. 그래서 나온게 미국의 재활법 501조 지요. 경제논리대로라면 미국의 재활법 501조야말로 아우토반역질주겠습니다만, 그렇게 경제논리만 따지면 소외되는 계층 들이 있기 때문에 법으로 강제하는 것입니다. 조만간 한국에도 비슷한 입법이 될 듯도 한데, 아마 그럼 "기업하기 힘든 세상"이라는 소리나 나올까요.

약간 보탭니다.

경제성이나 수익성은 따지기에 따라 답이 천차만별로 다르게 나올 수도 있습니다. 상호 운용성, 장치 독립성을 잘 유지하면서 더 나아가 보편적 접근성까지도 고려한 웹 사이트를 만드는데 들어가는 비용과 그로부터 생기는 이득 가운데 어느 것이 더 클까요? '경우에 따라 달라요'가 답이겠지요. 또, 같은 수치의 답을 보고도 해석이 달라질 수도 있고요. 그 기업의 성격, 대상 시장, 규모나 단기, 중기, 장기 비전에 따라 답이 다를 수도 있고요. 이득으로 잡을 항목에 어떤 '상상력'을 발휘하느냐에 따라 또는 그 사실을 어떻게 써 먹을 지에 대해서 - 전에 없었던 새로운 시장(예를 들어, 늘어나는 노령 인구를 겨냥한 시장)을 만들 수도 있고, 기업 PR 측면에서 무형의 이익을 생각할 수도 - 발휘하는 '상상력'에 따라서도 답은 다를 것입니다. BBC, IBM, HP, MS 등이 이런 부분에 신경을 많이 쓰는 이유에는 법률이나 규제 이외에 다른 (경제적) 요소도 있다고 봅니다. 항상 이른바 '일등만을 지향한다'는 삼성이 이런 데에 아직도 눈이 멀다는 것은 '안타까운' 일이겠지요.

http://www.appleforum.com/printthread.p ... ge=2&pp=15