파이어폭스의 예전 플러그인 모델이라고 할수 있는 XPCOM 기능이 지원 중단됩니다.
전자정부와 대법원등에서 파이어폭스를 지원하기 위해 액티브X대신 사용한게 XPCOM 모델이고,
IE Tab등도 XPCOM을 사용했기에 파이어폭스 3.6이후부터 호환이 안되게 됩니다.
자세한 내용은 차니님의 블로그 [url:7wq374po]http://blog.creation.net/395[/url:7wq374po] 참고
사이트들이 파이어폭스를 지원하려면 웹표준으로 지원을 해야지, 플러그인을 호환되게 만들어서는 근시안적인 해법밖에 안된다는 교훈.
뜨어… 딴건 몰라도 IE Tab은 타격이 좀 크겠는데요. 파폭에 적응 못하는 친구들을 위해 그걸 가르쳐주고 있는데… 덜덜
[quote="draco":30mvb93d]파이어폭스의 예전 플러그인 모델이라고 할수 있는 XPCOM 기능이 지원 중단됩니다.
전자정부와 대법원등에서 파이어폭스를 지원하기 위해 액티브X대신 사용한게 XPCOM 모델이고,
IE Tab등도 XPCOM을 사용했기에 파이어폭스 3.6이후부터 호환이 안되게 됩니다.
자세한 내용은 차니님의 블로그 [url:30mvb93d]http://blog.creation.net/395[/url:30mvb93d] 참고
사이트들이 파이어폭스를 지원하려면 웹표준으로 지원을 해야지, 플러그인을 호환되게 만들어서는 근시안적인 해법밖에 안된다는 교훈.[/quote:30mvb93d]
어차피 웹표준이 아닌, 사도의 길을 걷는 것 자체가 문제…;
여튼, 하루 빨리 웹표준을 준수했으면 하네요.
프로그래밍과 개발에 대해서 아무것도 아는 것은 없습니다만…웹 표준을 지키는 것이 그렇게 성가시고 힘든 일인가요??
[quote="lsuksl":w7it8eot]프로그래밍과 개발에 대해서 아무것도 아는 것은 없습니다만…웹 표준을 지키는 것이 그렇게 성가시고 힘든 일인가요??[/quote:w7it8eot]
기존 환경에 익숙해진 사람이 표준 준수를 하려면 좀 귀찮을 수는 있겠지요.
차선은 밟고 다니는 걸로 운전을 배운 사람이 차선지키려면 의식적으로 애를 좀 써야 되지 않겠습니까…? 하지만 차선 밟고 다니다 큰 사고를 치느니 일찌감치 버릇을 고치는 게 낫다는 거지요.
우리나라… 점점 전세계의 IT업계에서 "갈라파고스"가 되어가는 느낌입니다.
[quote="ieukori":2107x0ck][quote="lsuksl":2107x0ck]프로그래밍과 개발에 대해서 아무것도 아는 것은 없습니다만…웹 표준을 지키는 것이 그렇게 성가시고 힘든 일인가요??[/quote:2107x0ck]
기존 환경에 익숙해진 사람이 표준 준수를 하려면 좀 귀찮을 수는 있겠지요.
[/quote:2107x0ck]
표준을 준수하기 위해 들여야할 비용이 그렇게 큰 것인가가 궁금해졌습니다. 예를 들어 사용하는 프로그램을 버리고 새로운 상용프로그램을 써야한다든지 현재 시스템을 모조리 갈아 엎어야 표준을 준수할 수 있는 기반을 만들 수 있다든지의 기회비용? 매몰비용?이 생긴다면… 표준 준수앞에 갈등할 경우도 무시할 수 없을 것 같아서요.
단순히 익숙해지지 않았기 때문에 표준을 지키지 않는 편을 선택한다면 욕을 먹을수도 있는 일이니까요.
[quote="Vulpes":3d7ojj46]뜨어… 딴건 몰라도 IE Tab은 타격이 좀 크겠는데요. 파폭에 적응 못하는 친구들을 위해 그걸 가르쳐주고 있는데… 덜덜[/quote:3d7ojj46]
Firefox 3.7a1pre 버전에서는 일단 IE Tab은 동작은 하지만 정상적인 동작은 하질 않더군요.
렌더링 엔진전환을 하면 (저의 기준으로)검은 화면이 나올 뿐이고, 외부로 열면 IE가 실행되기에 문제는 없습니다.
대안이라고 하기엔 뭣하고 IE Tab의 업그레이드 확장기능이 있습니다.
[url=https://addons.mozilla.org/ko/firefox/addon/10909:3d7ojj46]Coral IE Tab[/url:3d7ojj46] 이라는 이름으로 기존의 IE Tab을 약간 업그레이드한 버전인 것 같군요. 사용법도 똑같기도 하구요.
[color=#FF0000:3d7ojj46]※ 특수기능에 Adbloc plus 지원이라고 있기는 하지만 정상적으로 동작을 하는 것인지는 의문입니다.[/color:3d7ojj46]
IE에서는 잘 되는데, 다른데서는 안되기 때문에 다양한 브라우저에서 동작되게 하려면
개발 비용이 그만큼 커지죠.
같은 페이지도 브라우저에 다라 다르게 보이기도 하구요.
다양성을 인정한다는 것은 그만큼 많은 생각을 해야되는거 같네요.
다양성을 제한하면, OSX 같은게 나오기도 합니다. =.=
(이건 상관 없는 말인가…)
ActiveX에서 다른 웹 ‘프로그래밍’ 언어로 갈아타는 거라면 좀 걸리기는 걸릴 지도…
(적어도 강의 문서를 안 보고도 원하는 작업들을 뚝딱 해치울 수 있게 될 때까지는)
사실 지금의 한국의 웹 환경의 더 정확한 문제점은
이 정도가 되겠지요. 저는 이제야 생각하기 시작한 겁니다만.
[quote="lsuksl":h1184hvk][quote="ieukori":h1184hvk][quote="lsuksl":h1184hvk]프로그래밍과 개발에 대해서 아무것도 아는 것은 없습니다만…웹 표준을 지키는 것이 그렇게 성가시고 힘든 일인가요??[/quote:h1184hvk]
기존 환경에 익숙해진 사람이 표준 준수를 하려면 좀 귀찮을 수는 있겠지요.
[/quote:h1184hvk]
표준을 준수하기 위해 들여야할 비용이 그렇게 큰 것인가가 궁금해졌습니다. 예를 들어 사용하는 프로그램을 버리고 새로운 상용프로그램을 써야한다든지 현재 시스템을 모조리 갈아 엎어야 표준을 준수할 수 있는 기반을 만들 수 있다든지의 기회비용? 매몰비용?이 생긴다면… 표준 준수앞에 갈등할 경우도 무시할 수 없을 것 같아서요.
단순히 익숙해지지 않았기 때문에 표준을 지키지 않는 편을 선택한다면 욕을 먹을수도 있는 일이니까요.[/quote:h1184hvk]
이 얘기를 읽으니 생각나는 게 있는데…
옛날에 CS101 수업을 들을 때 C 프로그래밍을 했죠. 근데 당시에 학교 PC실에 있던 컴파일러가 터보 C였습니다. 이 터보 C에서는 표준 C 라이브러리에는 없는 몇가지 편리한 함수들을 제공하고 있었는데 대표적인 것으로 getch() 같은 것이 있었습니다. 이 함수가 하는 일은 화면에서 사용자가 키 하나를 누르면 그 키의 ascii 코드를 리턴해주는 거였죠. 표준 C 라이브러리에 있는 함수들로는 동일한 기능을 해주지 않기 때문에 간단한 키 입력을 위해서 자주 사용되었죠. 예를 들면 "hit any key to continue…" 같은 문장 출력하고 키를 하나 누르면 다음을 계속하는 식이었습니다. 근데 이게 표준 C 라이브러리에 없는 것이기 때문에 PC실의 터보 C가 아닌 웍스테이션에 연결된 터미널에서 컴파일을 하려고 하면 당근 안되죠. 프로그램을 고치기 전에는. 고친다고 해도 동일한 동작을 하지는 않습니다. 그래서 친구에게 얘기합니다. "야, 표준에 없는 함수를 쓰고 xx이야!" 그러면 친구가 얘기합니다. "그냥 터보 C 써!"
^^ 이런 것과 비슷한 것 같습니다. (오래된 얘기라 틀린 부분이 있을 수 있습니다. 틀렸다고 뭐라 하시면 도망갑니다. 
)
[quote="lsuksl":2ue14yna][quote="ieukori":2ue14yna][quote="lsuksl":2ue14yna]프로그래밍과 개발에 대해서 아무것도 아는 것은 없습니다만…웹 표준을 지키는 것이 그렇게 성가시고 힘든 일인가요??[/quote:2ue14yna]
기존 환경에 익숙해진 사람이 표준 준수를 하려면 좀 귀찮을 수는 있겠지요.
[/quote:2ue14yna]
표준을 준수하기 위해 들여야할 비용이 그렇게 큰 것인가가 궁금해졌습니다. 예를 들어 사용하는 프로그램을 버리고 새로운 상용프로그램을 써야한다든지 현재 시스템을 모조리 갈아 엎어야 표준을 준수할 수 있는 기반을 만들 수 있다든지의 기회비용? 매몰비용?이 생긴다면… 표준 준수앞에 갈등할 경우도 무시할 수 없을 것 같아서요.
단순히 익숙해지지 않았기 때문에 표준을 지키지 않는 편을 선택한다면 욕을 먹을수도 있는 일이니까요.[/quote:2ue14yna]
표준 준수를 위한 비용은 당연히 들어갑니다. 표준을 고려하지 않고 만들어 댄( 사실은 싸질러 댄… 이라고 하고 싶지만…) 기존 시스템들을 갈아엎어야 하니까요. 하지만 한번 구축 후 영구불변하게 사용할 수 있는 시스템이란 게 존재할 수 없기 때문에, 기왕 손 댈 때 조금만 신경쓰면 큰 비용없이 처리할 수 있다고도 볼 수 있습니다.
대신 다른 측면에서 생각을 좀 해봐야 하는 게 이대로 표준을 준수하지 않는 시스템들이 그냥 남아있고, 추가적으로 개발되는 시스템들도 표준을 준수하지 않는다면 언젠가(조만간…) 빅뱅이 한번 올 거고… 그렇게 되면 비용 문제는 수준을 달리하는 고비용의 사태가 생기게 될 거라는 점입니다.
이건 단순히 웹만의 문제는 아니고, PC의 OS 문제나 핸드폰의 작동 환경 문제같은 것도 비슷하게 볼 수 있을 듯 합니다.
개인적으로는 애플을 별로라고 생각하지만, 최근 회자되고 있는 아이폰 도입에 대한 음모론이나 안드로이드 탑재 폰이 국내 출시되지 않는 문제 등등이 사실이라면 우리나라는 IT업계에서 퇴화하고 있는 중이겠지요. 이런 문제들도 결국 개방-표준준수-독점금지 등등의 "정상적인" 시장환경이 아니라는 우리나라만의 배경이 깔려있는 문제일 수 있습니다.
기존의 것들을 갈아 엎는게 부담 된다면 그렇겠구나 하겠지만…
새로 개발하는데 표준을 지키는게 그다지 어려운 일도 아니고, 비용도 적게 들겁니다.
엑티브엑스나 xpcom 같은 것들은 웹 개발 지식 외에도 윈도우 개발이나 혹은 해당 플러그인 개발을 위한 기술을 가지고 있어야 하지만…
웹표준은 웹프로그램만으로 구현가능하겠죠. 그러니 윈도 개발자 구할일도 없고, xpcom 같은 기술을 따로 배울일도 없고…
비용이 많이 들어갈만한 부분은 베리사인 같은데서 인증서 발급비용등이 비쌀 수 있는데…
그것도 보면 대부분 돈 많은 은행권인데다, 이미 https를 쓰고 있는데도 많아 보여 그걸로도 충분해 보이네요…
물론 대부분 그냥 만들어진 것들을 사와서 붙이기만 하니 엑티브엑스를 이용한 것들이 비용이 더 적을수도 있겠지만 웹으로 처리하게 한다해도 그런 솔루션 회사가 나오지 않을까요? https를 이용한 전자결제 솔루션 회사들이 외국에 없는것도 아니고, 우리나라도 허용이 되면 솔루션 업체가 나올 수도 있겠죠.
근데 지금 법으로 강제로 공인인증서라는 비표준 전자서명을 사용하게끔 해놓았으니 표준으로 불가능하니 비표준인 엑티브엑스나 플러그인 기술로 독자 구현해야만 하고… 그럼 결국 비표준 기술이 되는거고…
결국 법으로 강제놓은 부분이 더 문제라고 보이네요…
[quote="koxel":39vnckxo]기존의 것들을 갈아 엎는게 부담 된다면 그렇겠구나 하겠지만…
새로 개발하는데 표준을 지키는게 그다지 어려운 일도 아니고, 비용도 적게 들겁니다.
엑티브엑스나 xpcom 같은 것들은 웹 개발 지식 외에도 윈도우 개발이나 혹은 해당 플러그인 개발을 위한 기술을 가지고 있어야 하지만…
웹표준은 웹프로그램만으로 구현가능하겠죠. 그러니 윈도 개발자 구할일도 없고, xpcom 같은 기술을 따로 배울일도 없고…
비용이 많이 들어갈만한 부분은 베리사인 같은데서 인증서 발급비용등이 비쌀 수 있는데…
그것도 보면 대부분 돈 많은 은행권인데다, 이미 https를 쓰고 있는데도 많아 보여 그걸로도 충분해 보이네요…
물론 대부분 그냥 만들어진 것들을 사와서 붙이기만 하니 엑티브엑스를 이용한 것들이 비용이 더 적을수도 있겠지만 웹으로 처리하게 한다해도 그런 솔루션 회사가 나오지 않을까요? https를 이용한 전자결제 솔루션 회사들이 외국에 없는것도 아니고, 우리나라도 허용이 되면 솔루션 업체가 나올 수도 있겠죠.
근데 지금 법으로 강제로 공인인증서라는 비표준 전자서명을 사용하게끔 해놓았으니 표준으로 불가능하니 비표준인 엑티브엑스나 플러그인 기술로 독자 구현해야만 하고… 그럼 결국 비표준 기술이 되는거고…
결국 법으로 강제놓은 부분이 더 문제라고 보이네요…[/quote:39vnckxo]
현재 국내에서 개인이 전자상거래를 위해서 사용하는 공인인증서가 비표준은 아닙니다. 엄연히 표준 문서에 나와 있는 전자서명을 사용합니다. 심지어 대부분의 공인인증서는 우리나라에서 자체적으로 만든 HAS160 같은 해시 알고리즘과 KCDSA와 EC-KCDSA 같은 서명 알고리즘이 있음에도 불구하고 미국에서 만든 SHA와 RSA를 쓰는 실정입니다. (심지어 DSA도 안 씁니다.) 물론 앞에 언급한 모든 서명 알고리즘들이 ISO/IEC 표준에 포함돼 있습니다. 뭘 쓰든 표준에서 벗어나지 않죠.
사용되는 알고리즘 뿐 아니라 인증서가 저장되는 파일 형식도 RFC에 나와 있는 것들을 씁니다. 아래 화면은 우리은행에서 인터넷뱅킹 할 때 쓰던 인증서를 firefox에 불러 놓은 화면입니다. (에… 한 번 변환을 해줘야 하긴 합니다. 이건 표준에 어긋나서 변환을 하는 건 아닙니다. 원래 RFC에 정해지길 저장용 파일 형식과 정보교환용 파일 형식이 다릅니다.) 그러니 이것도 표준에서 벗어나지 않습니다.
[attachment=0:39vnckxo]cert.jpg[/attachment:39vnckxo]
그럼 문제가 뭐냐하면… 면면은 다 표준에 맞지만 전체적인 시스템이 돌아가는 방식이 괴상하다는 겁니다.
위 화면에 보시면 인증서가 알 수 없는 이유로 검증되지 않는다고 나옵니다. 알 수 없는 이유가 아니고, 인증서를 발급한 yessign이라는 곳의 공개키가 현재 제 firefox에 기본 포함되지 않았기 때문입니다. yessign의 공개키와 yessign의 상위기관에서 발급한 인증서를 넣어주면 검증이 되겠지요. (귀찮아서 해보진 않았습니다.) 공인인증서 발급받는 과정을 유심히 보신 분들은 기억하실 텐데, 은행거래용과 정부기관 홈페이지에서 사용하기 위한 용도의 공인인증서는 공짜로 발급해주지만, 그 외의 용도에도 사용할 수 있는 공인인증서는 제법 비싼 비용을 내야 발급해줍니다.
이유는 간단히 말해서 너무 많은 사람이 공인인증서를 사용하고 있기 때문입니다. -.-;; 제생각에는 그래서 공인인증서 발급이 이중화되어 있는 것 같습니다. 은행 거래용 인증서를 발급받는데 돈을 내라고 하면 전국민이 불평을 해댈 테고 소송도 불사하는 사람이 생기겠죠. 그렇다고 상위기관에서부터 차근차근 인증의 고리가 형성된 때깔 좋은 인증서를 다 발급하자니 발급하고 관리하는데도 비용이 듭니다. 근데 공짜로 발급하고 있죠. (결국 또 법으로 강제해서 그렇다는 얘기로 돌아가는 게 되는 것 같기도… ㅋㅋ)
그리고 지금 인터넷뱅킹으로 이체를 하려면 로그인할 때 인증서를 통해서 로그인을 했음에도 다시 인증서를 통해서 인증을 합니다. 이걸 그냥 https를 통해서 하려면 일단 세션을 끊고 다시 로그인하는 효과를 줘야 한다는 것인데, 굳이 하자면 그렇게 할 수도 있겠지만 지금 activex를 쓰는 방식과는 아무래도 다를 수밖에 없습니다. 앞에 터보C와 getch() 얘기가 그래서 쓴 겁니다.