정식 명칭은 Silverlight 4 Feburary 2011 Update이고요 흔히 GDR(General Distribution Release)은 메이저 버전이 가지고 있는 치명적이거나 긴급한 버그를 수정한 중간 릴리즈이죠. 아래에 언급한 현상이 아니라면 일반사용자 및 개발자 누구에게도 영향을 주지 않지만 혹시 모르니 둘러보시고 개발 환경을 업데이트 해주시는게 좋겠죠?

뭐, 언제나처럼 원문은 Tim Heuer가 작성하였고 저는 또 발 번역이네요. 뉴스 번역 전문 블로그가 되어가는 듯한 느낌 =_=;
http://timheuer.com/blog/archive/2011/02/14/silverlight-february-2011-update-gdr3.aspx

------------------------------------------------------------------------------------------
오늘 실버라이트 팀은 Silverlight 4 런타임 업데이트를 공개하였습니다. 내부적으로 "GDR3"라고 부르는 이 업데이트는 다음의 주요 사항을 업데이트 합니다(KB2495644 참고).

  • [1] VC-1 코덱의 미디어 재생시 타임스탬프 문제.
  • [2] 픽셀 셰이더를 포함하는 실버라이트 애플리케이션을 프로파일링 할 때 비주얼 스튜디오 IDE가 뻗는 현상.
  • [3] OSX의 64비트 파이어폭스가 32비트 프로세스 모드일 때도 실버라이트가 동작가능.
  • [4] 실버라이트 버전 업그레이드 이후 DRM으로 보호된 콘텐트를 재생할 때 발생하는 "6207" 오류 수정.
  • [5] 인라인 DataTemplate을 사용할 때 발생하는 메모리 누수현상 수정.
  • [6] 아웃오브브라우저 애플리케이션이 애플리케이션 이름이 변경되었을 때 업데이트에 실패하는 현상 수정.
  • [7] 미디어 스트림에 재지정(redirect) 정보를 포함할 때 발생하는 재생 오류 수정.
  • [8] 네트워크 지연시간 향상(감소^^) (KB2505882)
대부분의 독자(당연히 Tim의 블로그의 독자)는 이 메모리 릭 문제에 해당사항이 없을 것입니다. 이 이슈는 포럼에서 아주 지겹도록 논의하고/싸우고/놀림당한 것입니다. 혹시 고객의 애플리케이션이 이 문제를 겪고 있고 꽁수(workaround)를 적용하지 않았다면 고객에게 이 릴리즈를 적용할 것을 권유하고 싶을 것입니다. 이 릴리즈를 적용하는 것은 간단하게 실버라이트를 호스팅하는 <object>태그에 최소 버전(minimum version) 어트리뷰트를 사용하면 됩니다. 최소 버전을 수정하면 사용자는 업그레이드가 필요하다는 메시지를 받게 될 것입니다. 물론 이 전에도 여러번 말했듯이, 이런 업그레이드는 반드시 각 사이트 경험에 맞춰 수정하는 것이 좋고 심지어 우리는 설치 경험 백서를 통해 샘플 코드도 제공하고 있습니다.

'얼레? 내 문제는 여기에서 수정되지 않았는데요?'
각 서비스 릴리즈는 모든 문제를 완벽하게 해결하지 않습니다. 만약 이 업데이트를 적용한 후로 어떤 문제가 발생한다면 제발, 제발, 제발, 제~발 제품 버그로 알려주세요. 다른 누군가가 이미 했을거라고 넘겨짚지 마세요. 실버라이트에 관한 버그를 신고하려면 이 포스트의 가이드에 따르면 됩니다: 실버라이트에 관한 피드백을 전달하는 방법. 이상적인 버그는 상세하고, 재현가능하며, 재현가능한 프로젝트 샘플을 제공하는 것입니다. 이것이 버그를 이해하고 평가하는데 가장 빠른 길입니다.

업데이트 하기
다른 모든 서비스 업데이트와 같이, 이 업데이트는 마이크로소프트 (윈도우)업데이트를 통해 고객에게 제공될 것입니다. 만약 개발자라면 업데이트를 기다릴 필요 없이, 아래에서 다운로드할 수 있습니다(세계적으로 다운로드가 가능한 시점은 몇 시간 정도 걸릴 수도 있습니다.).
이번 릴리즈와 관련된 SDK 업데이트는 없습니다. 개발자라면 개발자 런타임만 업데이트하면 되고 일반 사용자라면 사용자 런타임만 업데이트하면 됩니다. 특히 개발자에게 강조하고 싶은 것은, 이 업데이트를 "강제로" (배포된) 애플리케이션에 적용하지 마세요. 대신 <object> 태그의 minRuntimeVersion을 통해 제어하면 해당 애플리케이션에 필요한 버전을 자동으로 적용할 수 있습니다.
------------------------------------------------------------------------------------------

변경된 사항을 좀 더 자세히 뒤져보죠.

- 업데이트 하기 전 최종 실버라이트의 버전은 4.0.51204.0 인데요, 업데이트 후에는 4.0.60129.0이 돼요.

- 이슈 1
VC-1 코덱으로 인코딩 된 미디어를 재생할 때 타임스탬프가 잘못된 값으로 변경되는 문제.
이 문제는 타임스탬프가 2의 48승 100나노초보다 큰 값을 포함할 때 발생합니다. 이 문제가 발생하면 다음과 같은 증상이 나타납니다.
  • 콘텐트를 재생할 때 동영상이 제대로 재생되지 않습니다. 그러나 오디오는 제대로 나옵니다.
  • Internet Explorer에서 콘텐트를 재생할 때 "Errors on Page" 메시지가 표시됩니다. 상세한 내용은 다음과 같습니다.
    a System.OverflowException exception is thrown together with the following call stack:
    mscorlib.dll!System.TimeSpan.Interval(double value, int scale) 
    System.Windows.dll!MS.Internal.XcpImports.ConvertCValueForManagedWithType(System.
    Type propertyType, ref MS.Internal.CValue outVal, int outDOType, bool 
    releaseObjectReference, bool deleteBuffer, MS.Internal.IManagedPeerBase fromObject 
    System.Windows.dll!MS.Internal.XcpImports.GetValue(MS.Internal.IManagedPeerBase 
    managedPeer, System.Windows.DependencyProperty property) 
- 이슈 5
인라인 DataTemplate을 사용할 때 메모리 누수 현상.
다음 포럼에서 논의된 바 있습니다. http://forums.silverlight.net/forums/t/171739.aspx

- 이슈 8
이것은 정확히는 버그 수정이 아니고 기능 추가인데요, 이 전 버전에 비해 90% 정도의 네트워크 지연이 개선되었답니다. 그렇지만 정확히 어떤 종류의 지연 시간이 개선되었는지는 테스트가 필요하겠네요.

아마도 인라인 데이터 템플릿의 메모리 릭 문제는 상당히 신경 쓰이는 부분이고 네트워크 지연 속도 개선도 꽤나 흥미롭네요. 언제나 그렇듯이, 당장 잘 돌아가는 애플리케이션에 어거지로 적용하는 것 보다는 문제가 있었던 것을 해결하는데 이용하는게 좋겠죠?


업데이트 인증샷 :D
저작자 표시 동일 조건 변경 허락
신고
Posted by gongdo

요즘 개발자들 사이에선 어딜가나 CES11이 화제더군요. 모종의 이유로 의욕저하 상태라 영상들을 보진 않았는데요, 기술적으로야 서피스2나 윈도폰7의 업데이트 소식에 관심이 가긴하지만 역시나 더 무게가 실리는 건 ‘다음 버전’의 윈도가 아닐까 싶어요.

바로 윈도8이죠.

물론, 공식적으로는 ‘다음 버전의 윈도’가 맞지만 편의상 저도 윈도8이라고 부를께요.

기다리면 당연하다는 듯이 나올 다음 버전의 윈도. 하지만 이번 윈도는 UI와 애플리케이션 모델에 있어서 지금까지 있었던 어떤 변화보다도 더 큰 변화가 있을 거란 소문이 파다해요. 그것도 꽤나 그.럴.싸.하.게.

지금부터 제가 말하는 내용은 거의 대부분 마이크로소프트 통인 Mary-Jo Foley의 블로그에 포스팅된 CES: Wil ‘Jupiter’ be key to Microsoft’s Windows 8 app store’s future?More on Microsoft ‘Jupiter’ and what it means for Windows 8에 더 자세히 소개하고 있어요.

아직 어떤 스크린샷이나 공식적인 언급은 없지만, 이미 웹 상에는 윈도8에 대해 많은 소문이 퍼져있죠. 그 중에서 가장 핵심적인 키워드는 ‘Mosh’와 ‘Jupiter’.

Mosh는 윈도8의 새로운 UI에 관한 코드명이고 Jupiter는 새로운 애플리케이션 모델에 관한 코드명이라고 해요.

코드명 Mosh는 타일 기반의 쉘 컨셉 즉, 윈도폰7에 탑재된바 있는 타일 기반의 UI 구성을 말하는데 웹에서 Windows 8 Mosh라고 검색해보면 꽤나 그럴싸한 소스의 소문이 돌아다니는 것을 볼 수 있고 사실이든 아니든 윈도8에 지금까지와는 다른 새로운 UI가 탑재될 것으로 예상할 수 있죠. 마이크로소프트는 이미 OEM 제조사로부터 슬레이트(iPad스타일)나 태블릿 PC를 위해 윈도폰 OS를 포팅시켜달라는 압력을 받고 있지만 아직 그것을 허용하지 않고 있죠. Mary Jo는 ‘주저한다’는 표현을 썼네요.

어쨌든, 코드명 Mosh가 사실이라고 가정한다면 윈도8은 실제로 의미있는 여러 이디션(edition)으로 출시될 가능성이 높겠죠. 지금까지 윈도의 이디션은 일반사용자에게 있어서 사실상 의미가 없었어요. 왜냐면 각 이디션별로 지원하는 기능이 결국은 동일한 플랫폼(x86, x64 PC)에서 구동하는 기능의 차이일 뿐이었으니까요. 그러나 윈도8은 ‘공식적’으로 x86이 아닌 ARM과 같은 SoC에서도 구동이 된다고 확인이 되었죠. 이 말은 단순한 기능상의 차이를 떠나서 각 OEM 제조사가 입맛에 맞는 기능을 추가하거나 삭제하는 등의 풀 커스터마이징이 가능하다는 얘기고 이럴 때의 이디션 차이는 상당히 의미가 있다고 할 수 있을거에요. 물론 이디션이 차이가 나더라도 한번 작성한 애플리케이션은 하드웨어적인 요구사항만 만족한다면 여러 머신에서 실행이 가능하겠죠.

코드명 Mosh가 어느 수준의 UI 변화를 가져올지 심지어 그것이 적용될지 안될지도 모르지만 윈도8은 여러 종류의 디바이스의 요구사항을 만족하는 형태로 등장할 것이라는 점은 거의 확실하다고 생각해요.

Mary Jo도 그랬지만 저에게도 Mosh보다는 Jupiter에 더 흥미가 있어요. 코드명 Jupiter는 윈도8의 새로운 앱 모델이라고 해요. 다음은 Mary Jo가 인용한 Windows 8에 대한 루머의 원문인 New Tile-Based Shell, App Model, And App Store Coming In Windows 8?를 쓴 Paul Thurrott의 말을 보면,

(윈도8의) 앱 스토어는 AppX 패키지(.appx)로 배포되는 새로운 실버라이트 기반의 이머시브(immersive) 애플리케이션을 제공할 것이다. 내 소스에 의하면 윈도와 오피스 팀은 새로운 앱 형식에 빡세게 투자하고 있고 이미 베타 버전의 비주얼 스튜디오 2012을 개발에 사용하고 있다. 이 새로운 앱은 C#, VB.NET 심지어 C++로 작성할 수 있다.

라고 하는군요. 물론! 공식적으로 확인되지 않은 얘기임은 명심하시고요.

특히 윈도에 내장된 앱 스토어에 관해서는 이미 지난해 누출된 윈도8 계획 슬라이드에서 그 존재가 살짝 드러났고 이미 윈도폰 마켓 플레이스를 통하여 실버라이트와 XNA를 기반으로 한 앱을 배포하고 있기 때문에 코드명 Jupiter는 그 세부적인 사실이 어찌되었건 상당히 높은 가능성을 가지고 있죠.

또한 Mary Jo가 이미 다 정리를 해놔서 거의 그대로 옮기자면; 코드명 Jupiter은 윈도8에 기본으로 탑재되는 앱 모델로 XAML을 기반으로 한 UI 레이어를 구성하며 이를 통해 보다 부드럽고 유동적인 애니메이션, 타이포그라피, 미디어 기능을 제공할 것이라고 해요. 놀랍지도 않지만, 이러한 기능들은 바로 실버라이트 5의 새로운 기능이기도 하죠.

이건 제 의견이지만 마이크로소프트는 어쩌면 XAML을 기반으로 한 UI 패러다임의 전환을 확신하지 못했거나, 너무 큰 반발에 부딪쳤거나, 시대의 격변이나, 혹은 기술(SW/HW 양면)의 제약으로 충분한 성능을 내지 못했거나 하는 등의 이유로 XAML 기반의 UI 도입을 너무나도 미뤄왔을거에요. 이유야 어쨌든 지금 이 시점에서는 게임과 같은 복잡하고 고성능을 요구하는 UI가 아닌 일반적인 앱의 경우 XAML을 기반으로 한 애플리케이션 개발 모델은 전통적인 개발 모델에 비해 확실한 비교 우위를 가지고 있고 다른 뚜렷한 대안이 없는 이상 이 전략은 앞으로도 유효하다고 생각해요. (심지어 성능이 매우 중요한 그래픽적 처리또한 시간이 지나면서 XAML 기반의 개발로도 충분히 흡수할 수 있을거라고 생각하고요.) 아니, 다른 대안이 없는 이상 현재로서 가장 가능성있는 모델은 코드명 Jupiter가 설명하는 바로 그것 밖에 없다는 것일지도 모르죠.

여튼, 마이크로소프트는 이 새로운 모델의 앱을 “immersive” (뭐라고 해석하죠? 몰입형?) 앱이라고 부르며 이 immersive 앱은 단지 데스크탑 앱만을 말하는 것도 아니며 또한 순수한(HTML+CSS+JS) 웹 앱만을 말하는 것도 아니며 윈도8의 앱 모델 내에서 구동될 수 있는 모든 형태의 앱을 말한다고 해요.

코드명 Jupiter가 시사하는 바는 명확하게 실버라이트의 미래를 의미해요.

IT쪽에 발좀 걸치고 있다고 하는 많은 분들이 실버라이트를 시시껄렁한, 그것도 이미 사그라든 UI 기술 정도로 치부하고 있는 것이 사실이죠. 백보 양보하여 핵심적으로는 -UI는 결국 응용수준이지 core 수준은 아니기 때문에-맞는 말이라고 해도, 이것이 데스크탑 시장의 90%이상을 점유하고 있는 윈도라는 OS의 기본 애플리케이션 모델을 개발하는 기술이다라고 하면 그 무게감은 확실히 달라질거에요.

코드명 Jupiter가 사실이라고 가정한다면, 단순히 웹 브라우저 플러그인으로 시작한 실버라이트가 이제는 OS 레벨의 기본 UI 프레임워크로서 자리를 잡게 된다는 것을 의미하며 이미 윈도폰7은 그것이 가능하다는 것을 증명하는 사례라고 할 수 있을거에요. 또한 실버라이트 5의 가장 충격적인(?) 기능, P/Invoke의 존재는 OS 레벨의 통합을 뒷받침하는 강력한 증거라고 할 수 있어요.

한편, 보다 거대한 흐름에서 데스크탑 OS는 점유율이 날로 축소되고 있는 것도 사실이며 바로 이 때문에 마이크로소프트는 (항상 그렇듯이) 늦었지만 전력을 다해 모바일과 클라우드에 투자를 하고 있죠. HTML5는 특히 컨슈머용 앱에 있어서 킬러 플랫폼이 될 가능성이 크지만, who knows? 누가 섣불리 예측할 수 있겠어요? 3D 게임 소스가 널려있다고 해서 모두가 다 3D 게임 개발자가 될 수는 없잖아요? 다만 한가지 확실한 사실은 실버라이트가 미래에도 경쟁력을 가지려면 보다 넓은 플랫폼에서 동작을 보증해야 하고 그런 점에서 윈도 자체의 발전 방향은 올바르다고 할 수 있어요.

또 한편으로 애플의 OS는 포기하손치더라도 자유로운 리눅스쪽에 실버라이트가 (제대로, 간편하게)포팅될 수 없다는 사실은 상당히 아쉬운 점으로 남네요. 비즈니스적인 관점에서 데스크탑으로서의 리눅스는 전혀 고려대상이 아니지만 아무래도 임베디드나 모바일은 리눅스가 기본이라고 봐야하니까요.

막판에 조금 심각해지긴 했지만, 역시나 이런 뉴스들은 가볍게 보는 게 재밌어요. 요 몇년새 답이 안보이던 마이크로소프트가 과연 이러한 전략들로 다시 예전의 영광을 찾을 수 있을 것인가! 저 높은 곳에서 치열하게 싸우고 있는 클라우드시장의 향방은? 마이크로소프트와 반대로 요 몇년새 최전성기를 누리고 있는 애플의 독주는 과연 계속 될 것인가? 구글의 본격 세계 정복은 언제쯤? 기대하시라 개봉박두!

 

저작자 표시 동일 조건 변경 허락
신고
Posted by gongdo
당분간 최상단에 배치합니다.

read more...

신고
Posted by gongdo


티스토리 툴바