KR20080028869A - 콘텐트 신디케이션 플랫폼 - Google Patents

Abstract

웹 콘텐트 신디케이션 플랫폼과 같은 콘텐트 신디케이션 플랫폼은 인터넷으로부터 획득되는 콘텐트를 관리하고, 조직하며, 또한 그러한 콘텐트를 소비가능한 상태로 하는데 이용될 수 있다. 적어도 일부 실시예에서, 플랫폼은 웹 콘텐트를 획득하고, 조직할 수 있으며, 이러한 콘텐트를 상이한 유형의 많은 애플리케이션들이 소비할 수 있게 한다. 이들 애플리케이션은 특정한 신디케이션 포맷을 반드시 이해할 수도 있고, 이해하지 못할 수도 있다. API는 애플리케이션과 사용자가 피드의 생성, 판독, 갱신, 삭제 등과 같은 여러 상이한 태스크를 용이하게 수행할 수 있게 하는 객체 모델을 노출시킨다.

신디케이션, 플랫폼, 피드, API, RSS 데이터, 인클로저, 공통 포맷, 객체 모델

Description

콘텐트 신디케이션 플랫폼{CONTENT SYNDICATION PLATFORM}

RSS( R eally S imple S yndication)는 웹 콘텐트 신디케이션 포맷의 한가지 유형이다. RSS 웹 피드(feed)는 웹 상에서 점점 더 대중화되고 있고, RSS 지원 기능이 있는 많은 소프트웨어 애플리케이션이 개발되고 있다. 이들 많은 애플리케이션들은 여러가지 변화되는 특징을 가질 수 있고, 사용자가 몇몇의 상이한 RSS 인에이블(RSS-enabled) 애플리케이션을 설치할 수 있게 한다. 각 RSS 애플리케이션은 통상적으로 고유의 구독 리스트를 가질 것이다. 구독 리스트가 작으면, 사용자가 상이한 애플리케이션 전반에 걸쳐 이러한 구독을 입력하고, 관리하는 것이 상당히 용이하다. 그러나, 구독 리스트가 커짐에 따라, 이들 상이한 RSS 인에이블 애플리케이션 각각과 연결된 구독의 관리가 매우 어려워진다. 따라서, 구독 리스트가 비동기화되기 쉽상이다.

또한, 웹 피드는 몇몇의 상이한 파일 포맷 - 가장 일반적인 것은 RSS 0.91, 0.92, 1.0, 2.0 및 Atom -으로 나타난다. 각 RSS 인에이블 애플리케이션은 대부분의 이들 포맷을 지원해야 하고, 미래에는 점점 더 많이 지원해야 할 가능성도 있다. 일부 애플리케이션을 위한 RSS 콘텍스트의 사용에 파서(parser)를 구현하는 것은 다른 것에 비해 매우 어렵다. 모든 애플리케이션 개발업자가 각 포맷의 복잡함에 관하여 경험과 지식이 있는 RSS 전문가는 아니므로, 모든 애플리케이션 개발 업자가 파서를 정확하게 구현하기는 매우 어렵다. 따라서, 많은 수의 파일 포맷이 존재하는 상황에서, 일부 애플리케이션 개발업자는 이 공간에서 애플리케이션을 개발하지 않기로 선택하고, 또는 만약 개발업자가 개발을 하더라도, 그 애플리케이션은 상이한 파일 포맷에 걸쳐 이용가능한 모든 특징을 전체적으로 이용하도록 구성되지는 않을 것이다.

RSS 및 웹 피드의 다른 실시 양태는 콘텐트의 게시에 관련된다. 예컨대, 블로그(웹로그)를 사용하는 사용자의 수가 증가하고 있다. 무료 블로그 서비스를 제공하는 공개적으로 이용가능한 서비스도 다수 있다. 그러나, 블로그 서비스에 콘텐트를 게시하는 것은 브라우저를 열고, 블로그 서비스를 탐색하고, 로그인하고, 엔트리를 타이핑하고, 이를 전송하는 것을 포함하기 때문에, 다소 귀찮을 수 있다. 많은 애플리케이션 개발업자들은 웹사이트를 방문해야만 하는 것에 의해 사용자의 흐름을 방해하지 않으면서, 그들의 특정 애플리케이션 내로부터 게시할 수 있는 것을 선호한다. 또한, 클라이언트 장치와 특정 서비스 간의 통신에 사용될 수 있는 많은 상이한 유형의 프로토콜들이 존재한다. 이러한 상황에서, 애플리케이션 개발업자들이 모든 프로토콜을 구현하기는 어려워보인다. 이와 같이, 사용자의 경험이 가능한 전부는 아닐 것이다.

웹 콘텐트 신디케이션 플랫폼과 같은 콘텐트 신디케이션 플랫폼은 예컨대, 인터넷, 인트라넷, 사설 네트워크 또는 다른 컴퓨팅 장치와 같은 소스로부터 획득되는 콘텐트를 관리하고, 조직하며, 또한 그러한 콘텐트를 소비가능한 상태로 하는데 이용될 수 있다. 일부 실시예에서, 플랫폼은 웹 콘텐트를 획득하고, 조직할 수 있으며, 이러한 콘텐트를 상이한 유형의 많은 애플리케이션들이 소비할 수 있게 한다. 이들 애플리케이션은 특정한 신디케이션 포맷을 반드시 이해할 수도 있고, 이해하지 못할 수도 있다. API(application program interface)는 애플리케이션과 사용자가 피드의 생성, 판독, 갱신, 삭제 등과 같은 여러 상이한 태스크를 용이하게 수행할 수 있게 하는 객체 모델을 노출시킨다.

또한, 플랫폼은 플랫폼으로 들어오는 피드 데이터의 이용가능성을 향상시키는 공통 포맷을 제공하기 위하여 특정 피드 포맷을 무시할 수 있다. 또한, 플랫폼은, 웹 피드를 통해 수신될 수 있는 인클로저를, 신디케이션 인식(syndication-aware) 애플리케이션과 신디케이션 비인식 애플리케이션 모두가 그 인클로저를 소비할 수 있게 하는 방식으로 처리하고 관리한다.

도 1은 일 실시예에 따른 웹 콘텐트 신디케이션 플랫폼을 포함하는 시스템을 도시하는 상위 레벨 블록도.

도 2는 일 실시예에 따른 객체 모델의 실시 양태를 도시하는 블록도.

도 3은 일 실시예에 따른 피드 동기화 엔진을 도시하는 블록도.

도 4는 일 실시예에 따른 예시적인 피드 저장부(feed store)를 도시하는 도면.

도 5는 일 실시예에 따른 예시적인 사용자의 프로필을 도시하는 도면.

도 6은 일 실시예에 따른 예시적인 객체를 도시하는 도면.

도 7은 일 실시예에 따른 예시적인 객체를 도시하는 도면.

개관

예컨대 인터넷, 인트라넷, 사설 네트워크 또는 다른 컴퓨팅 장치와 같은 소스로부터 획득되는 콘텐트를 관리하고, 조직하며, 또한 그러한 콘텐트를 소비가능한 상태로 하는 데 이용가능한 웹 콘텐트 신디케이션 플랫폼과 같은 콘텐트 신디케이션 플랫폼이 설명된다. 본 명세서와 관련해서는, 플랫폼은 RSS 웹 피드의 콘텍스트에서 사용되도록 설계되는 RSS 플랫폼의 콘텍스트로 설명된다. RSS 콘텍스트는 단지 하나의 일례를 구성하고, 청구 대상의 적용을 단지 RSS 콘텍스트에 한정하려는 의도가 아님을 이해할 것이다. 이하의 설명은 독자가 RSS에 어느 정도 정통함을 가정한다. RSS의 배경 기술에 대해서는, 독자가 관심을 가질 수 있는 정보를 제공하는 다수의 공개적으로 이용가능한 설명서가 있다.

이 명세서에서, 어떤 용어는 설명되는 RSS의 콘텍스트에서 사용될 것이다. 아이템( item )은 피드의 기본 유닛이다. 통상적으로, 아이템은 웹사이트 상의 실제 기사에 대해 링크된, 블로그 엔트리 또는 뉴스 기사/요약서를 나타낸다. 인클로저( enclosure )는 실제 콘텐트에 대한 링크가 존재한다는 점을 제외하고는, 이메일 첨부와 유사하다. 피드(feed)는 리소스 내의 아이템의 리스트로서, 대개는 가장 최근의 추가 사항만을 말한다. 시스템 피드 리스트( system feed list )는 사용자가 구독하는 피드의 리스트이다. 구독( subscription )은 새로운 피드 아이템의 통지를 수신하기 위하여 가입하는 행동을 말한다.

이 명세서에서 설명되는 다양한 실시예에서, 플랫폼은 웹 콘텐트를 획득하고 조직할 수 있고, 이러한 콘텐트를 여러 상이한 유형의 애플리케이션들에 의한 소비에 이용가능하게 할 수 있다. 이들 애플리케이션은 특정 신디케이션 포맷을 반드시 이해할 수도 있고, 이해하지 못할 수도 있다. 따라서, 구현 예에서는, RSS 포맷을 이해하지 못하는 애플리케이션이 그럼에도 불구하고 RSS 피드를 통해 플랫폼에 의해 획득되는 인클로저와 같은 콘텐트를, 플랫폼을 통해 획득하고 소비할 수 있다.

플랫폼은 애플리케이션과 사용자가 피드의 생성, 판독, 갱신, 삭제 등과 같은 여러 상이한 태스크를 용이하게 수행할 수 있게 하는 객체 모델을 노출시키는 API를 포함한다. 예컨대, API를 사용하면, 피드의 리스트를 포함하는 피드 리스트(feedlist)를 여러 상이한 유형의 애플리케이션들이 액세스하고, 관리하고, 소비할 수 있다.

적어도 일 실시예에서, 플랫폼은 복수의 상이한 피드 파서를 제공하며, 이 파서 각각은 웹 피드가 수신될 수 있는 특정 포맷을 구문 분석할 수 있다. 그 후, 구문 분석된 포맷은 애플리케이션과 사용자가 사용할 수 있는 공통 포맷( common format)으로 변환된다. 공통 포맷은 보다 범용의 이해가능한 포맷을 위하여, 어떤 하나의 특정 포맷에 의해 실시되는 특정 개념을 무시하고 사용된다.

또한, 플랫폼은, 웹 피드를 통해 수신될 수 있는 인클로저를, 신디케이션 인식 애플리케이션과 신디케이션 비인식 애플리케이션 모두가 그 인클로저를 소비할 수 있게 하는 방식으로 처리하고 관리한다. 적어도 일부 실시예에서는, API가 인 클로저와 그와 연관된 피드 아이템 사이의 관계를 발견하는 것을 허용한다.

이하의 논의에서는, 예시적인 플랫폼 및 그 컴포넌트가 "웹 콘텐트 신디케이션 플랫폼"이라는 제목 하에서 먼저 설명된다. 이 논의에 이어, ("구현 예"라는 제목 하에서) 구현 예가 제공되고, 애플리케이션과 사용자가 의미있고 확고한 방식으로 플랫폼과 상호작용할 수 있게 하는 객체 모델을 노출시키는 API들의 세트를 설명한다.

웹 콘텐트 신디케이션 플랫폼

도 1은 일반적으로 참조부호 100으로 표시되는, 일 실시예에 따른 예시적인 시스템을 도시한다. 시스템(100)의 실시 양태는 임의의 적절한 하드웨어, 소프트웨어, 펌웨어 또는 이들의 조합과 관련되어 구현될 수 있다. 적어도 일 실시예에서는, 시스템의 실시 양태가 몇몇 유형의 컴퓨터 판독가능 매체 상에 존재하는 컴퓨터 판독가능 명령어로서 구현된다.

이 예에서, 시스템(100)은 콘텐트 신디케이션 플랫폼(102) 및 애플리케이션들의 콜렉션(104)을 포함하며, 애플리케이션들의 콜렉션(104)의 각 애플리케이션은 이하에서 명백해지는 바와 같이 상이한 방식으로 플랫폼을 사용하도록 구성될 수 있다. 적어도 일부 실시예에서는, 콘텐트 신디케이션 플랫폼은 웹 콘텐트 신디케이션 플랫폼을 포함한다. 이하의 논의에서, 플랫폼(102)은 RSS 플랫폼의 콘텍스트에서 설명된다. 이는 단지 하나의 예일 뿐이고, 청구 대상의 적용을 단지 RSS 환경에만 한정하려는 의도가 아님을 이해할 것이다. 오히려, 설명되는 실시예의 원 리는 청구 대상의 정신과 범위를 벗어나지 않고도, 다른 신디케이션 환경에서도 사용될 수 있다.

이 예에서, 플랫폼(102)은, 애플리케이션(104)이 플랫폼과 상호작용할 수 있게 하는 API들의 세트에 의해 노출되는 객체 모델(106)을 포함한다. 동기화 엔진(108)은 다른 것들 중에서도, 웹 콘텐트를 획득하고, 적어도 일부 실시예에서는, 웹 콘텐트를 이하에서 상술하는 소위 말하는 공통 포맷으로 변환하도록 제공되고 구성된다.

게시 엔진(publishing engine)(110)은, 사용자의 애플리케이션 또는 컴퓨팅 장치와 콘텐트를 수신할 서버 또는 대상(destination) 소프트웨어 사이의 통신에 사용되는 통신 프로토콜을 무시하는 방식으로, API를 통해, 사용자가 블로그와 같은 콘텐트를 게시할 수 있게 한다.

또한, 적어도 일 실시예에서는, 플랫폼(102)은 피드 리스트(114) 및 피드 데이터(116) 모두를 저장하는 피드 저장부(112)를 포함한다. 또한, 적어도 일 실시예에서, 플랫폼(102)은 인클로저(120)를 저장하고 유지하기 위하여 파일 시스템(118)을 사용한다. 파일 시스템을 사용하면, 반드시 신디케이션 포맷을 이해하지는 않는 애플리케이션이 그럼에도 불구하고 관심이 있는 인클로저를 역시 소비할 수 있게 해준다는 점을 인에이블하는 것을 비롯한 이점이 있다. 또한, 플랫폼(102)은 특정한 웹 액세스 가능 위치로 포스팅될 포스트 데이터(124)를 유지하는 포스트 큐(post queue)(122)를 포함한다.

위에서 언급된 바와 같이, 플랫폼(102)은 애플리케이션이 웹 콘텐트를 액세 스하고, 소비하고, 게시할 수 있게 한다. 따라서, 애플리케이션들의 콜렉션(104)은 여러 상이한 유형의 애플리케이션들을 포함할 수 있다. 적어도 일부 실시예에서, 애플리케이션의 유형은 신디케이션 인식 애플리케이션과 신디케이션 비인식 애플리케이션을 포함할 수 있다. "신디케이션 인식"은 사용되는 신디케이션 포맷에 애플리케이션이 어느 정도 정통한 것을 의미한다. 따라서, RSS 콘텍스트에서, 신디케이션 인식 애플리케이션은 데이터를 처리하도록 구성될 수 있거나 아니면 RSS 포맷으로 나타나는 콘텐트와 상호작용하도록 구성될 수 있는 애플리케이션이다. 이는 RSS 포맷된 데이터를 구문 분석하는 능력 또는 이와 의미있게 상호작용하는 능력을 갖는 것을 포함할 수 있다. 마찬가지로, 신디케이션 비인식 애플리케이션은 통상적으로 신디케이션 포맷을 이해하도록 구성되지 않는다. 그러나, 이하에서 명백해지는 바와 같이, 신디케이션 비인식 애플리케이션은, 플랫폼을 통해, 신디케이션 포맷으로 플랫폼에 도달하는 콘텐트를 여전히 액세스하고 소비할 수 있다.

플랫폼과 상호작용할 수 있는 상이한 유형의 애플리케이션들을 보다 구체적으로 살펴보면, 콜렉션(104)은 웹 브라우저 애플리케이션(122), RSS 판독기(reader) 애플리케이션(124), 디지털 이미지 라이브러리 애플리케이션(126), 미디어 플레이어 애플리케이션(128) 및 블로그 서비스(130)를 포함한다. 이 예에서, RSS 판독기 애플리케이션(124)은 신디케이션 인식 애플리케이션이지만, 미디어 플레이어(128)가 반드시 신디케이션 인식 애플리케이션일 필요는 없다. 또한, 웹 브라우저 애플리케이션(122)은 신디케이션 인식 애플리케이션일 수도, 아닐 수도 있다. 물론, 이들 애플리케이션은 플랫폼과 상호작용할 수 있는 상이한 유형의 애플 리케이션들의 예일 뿐이다. 이와 같이, 도시된 것과 동일하거나 상이한 다른 유형의 애플리케이션이 청구 대상의 정신 및 범위를 벗어나지 않고도 사용될 수 있다. 예로서, 이러한 다른 유형의 애플리케이션은 이벤트 피드를 위한 캘린더 애플리케이션, 콘택트 피드를 위한 사회적 네트워킹 및 이메일 애플리케이션, 사진 피드를 위한 스크린 세이버 애플리케이션, 문서 피드를 위한 CRM 등을 포함할 수 있지만, 이에 한정되지 않는다.

이하의 논의에서, 플랫폼(102)의 개개의 컴포넌트의 실시 양태가 각각의 제목하에서 보다 자세히 설명된다.

객체 모델

도 2는 일 실시예에 따른 객체 모델(106)의 개별적인 객체를 도시한다. 설명되는 객체 모델은 사용될 수 있는 객체 모델의 단지 일례를 구성하며, 이하 설명되는 객체 모델에만 청구 대상의 적용을 한정하려는 의도는 아니다. 위에서 언급된 바와 같이, 객체 모델은 이하에서 그 일례가 설명되는 API에 의해 노출된다.

이 특정한 객체 모델에서는, 피드(feeds)로 불리는 상위 레벨 객체(200)가 제공된다. 피드 객체(200)는 폴더 유형의 구독(subscriptions)으로 불리는 속성을 갖는다. 구독 또는 폴더 객체(202)는 폴더들의 계층으로서 모델화된다. 따라서, 이 특정한 예에서, 구독 또는 폴더 객체는 폴더 유형의 서브폴더( subfolders )(204) 및 피드 유형의 피 드 ( feeds )(206)를 포함하는 속성을 갖는다. 피드 객체(206)의 아래에는 아이템 유형의 아이템 객체(208)가 있고, 아이템 객체(206)의 아래에는 객체 유형의 인클로저 객체(210)가 있다.

객체 모델의 개개의 객체는 속성, 메소드, 및 일부 경우에서는, 플랫폼에 의해 수신되는 웹 콘텐트를 관리하기 위하여 사용될 수 있는 이벤트를 갖는다. 위에서 설명된 객체 모델은 계층 구조가 피드 리스트 등을 관리하는 일을 하는데 사용될 수 있게 한다. 예컨대, 폴더 구조를 사용하면, 플랫폼이 피드의 세트에 대하여 실행될 수 있다. 당업자에게 명백한 바와 같이, 이에 의해 애플리케이션 개발업자는 훨씬 수월해진다. 예컨대, 피드의 세트에 대하여 실행하면, 뉴스 폴더 내에 위치된 "뉴스" 피드 전부를 리프레시하는 능력을 제공한다.

예로서, 이하를 고려한다. 사용자가 자신이 실제로 구독하지 않는 피드와 연관된 데이터와 상호작용하거나 이를 소비하고 싶어한다고 가정한다. 구독하는 피드, 즉 루트 레벨의 구독 폴더 내에 나타나는 피드에 대하여, 동기화 엔진(108)(도 1)은 피드를 포착하고, 적절한 인터벌에서 그 피드와 연관된 데이터를 페치(fetch)하기 시작할 것이다. 그러나, 플랫폼을 사용하는 애플리케이션이 특정 피드를 구독하고 싶어하지 않는 경우도 있다. 오히려, 애플리케이션은 피드로부터의 데이터를 액세스하기 위해서만 플랫폼의 기능을 사용하고 싶어한다. 이 경우, 이 특정한 실시예에서는, 구독 객체(202)는 피드를 구독하지 않고, 피드가 다운로드되게 하는 메소드를 지원한다. 이 특정한 예에서, 애플리케이션은 이 메소드(method)를 호출하고, 이 메소드에 피드와 연관된 URL을 제공한다. 그러면, 플랫폼은 애플리케이션이 관심 있어 하는 데이터를 페치하기 위하여 그 URL을 사용한다. 이 방식으로, 애플리케이션은 피드를 구독할 필요 없이도 그 피드와 연관된 데이터를 애드혹(adhoc) 방식으로 획득할 수 있다.

객체 모델을 더욱 고려하기 위하여, 아이템 객체(208)와 인클로저 객체(210)를 각각 고려한다. 여기서, 이들 객체는 RSS 그 자체가 구성되는 방법을 자세히 반영한다. 즉, 각 RSS 피드는 내부에 인클로저가 선택적으로 나타날 수 있는 개개의 아이템을 갖는다. 따라서, 객체 모델의 구조는 신디케이션 포맷의 구조를 반영하도록 구성된다.

객체 모델 관점으로부터, 아이템에 대한 속성 및 메소드에는 기본적으로 2개의 상이한 유형이 있다. 제1 유형의 메소드/속성은 판독 전용인 데이터에 관한 것이고, 제2 유형의 메소드/속성은 판독 및 기입 모두 될 수 있는 데이터에 관한 것이다.

제1 유형의 메소드 속성의 일례로서, 이하를 고려한다. 각 피드는 XML 구조로 표시되는 피드 연관 데이터를 포함할 수 있다. 이 데이터는 명칭, 저자, 언어 등과 같은 것을 포함한다. 이와 같은 데이터는 객체 모델에 의해 판독 전용으로서 취급된다. 예컨대, 피드에 의해 수신되고, 개개의 아이템과 연관된 데이터는 통상적으로 판독 전용으로서 취급된다. 이는 애플리케이션이 이 데이터를 조작하는 것을 금지한다. 또한, 피드 데이터를 나타내기 위하여 XML 구조를 사용하면 이하와 같은 이점이 있다. 추가된 새로운 XML 구성요소를 동기화 엔진이 이해하지 못한다고 가정한다. 그럼에도 불구하고, 동기화 엔진은 여전히 피드 아이템 데이터의 일부로서 그 구성 요소 및 연관된 데이터를 저장할 수 있다. 구성 요소를 이해하는 애플리케이션들에 대하여, 이 구성 요소 및 연관된 데이터는 여전히 애플리케이션 이 발견하고 소비하는데 이용가능하다.

한편, 특정한 피드의 이름과 같이, 판독/기입 데이터로서 취급되는 데이터가 존재한다. 즉, 사용자가 특정한 사용자 인터페이스를 위하여 특정한 피드를 개인화(personalize)하고 싶어할 수 있다. 이 경우, 객체 모델은 판독/기입 속성을 갖는다. 예컨대, 사용자는 피드의 이름을 "뉴욕 타임즈(New York Times)"에서 "NYT"로 바꾸고 싶어할 수 있다. 이 상황에서, 이름 속성은 판독가능하고, 기입가능할 것이다.

피드 동기화 엔진

도시되고 설명되는 실시예에서, 피드 동기화 엔진(108)(도 1)은 소스로부터 RSS 피드를 다운로드할 책임이 있다. 소스는 웹 사이트, 피드 게시 사이트 등과 같이 피드를 위한 임의의 적절한 소스를 포함할 수 있다. 적어도 일 실시예에서, 임의의 적절한 유효 URL 또는 리소스 식별자는 피드의 소스를 포함할 수 있다. 동기화 엔진은 피드를 수신하고, 다양한 피드 포맷을 처리하고, 스케쥴링을 살피고, 콘텐트 및 인클로저 다운로드를 다룰 뿐만 아니라, 아카이빙 액티비티(archiving activity)를 조직한다.

도 3은 일 실시예에 따라 보다 상세하게 나타낸 예시적인 피드 동기화 엔진(108)을 도시한다. 이 실시예에서, 동기화 엔진은 피드 포맷 모듈(300), 피드 스케쥴 모듈(302), 피드 콘텐트 다운로드 모듈(304), 인클로저 다운로드 모듈(306) 및 아카이빙 모듈(368)을 포함한다. 이들 모듈은 특정한 기능들을 분명히 설명하 기 위하여 논리적으로 분리된 모듈로서 도시되어 있음을 이해할 것이다. 논리적으로 분리된 모듈은 청구 대상을 여기서 설명되는 특정한 구조 또는 아키텍처로만 한정하려는 의도가 아니다.

피드 포맷 모듈 -- 300

도시되고 설명되는 실시예에서, 피드는 다수의 상이한 피드 포맷으로 수신될 수 있다. 예로서, 이들 피드 포맷은 RSS 1.0, 1.1, .9x, 2.0, Atom .3 등을 포함할 수 있지만, 이에 한정되지 않는다. 동기화 엔진은 피드 포맷 모듈을 통해 다양한 포맷의 이들 피드를 수신하고, 포맷을 구문 분석하고, 포맷을 공통 포맷이라고 칭해지는 표준(normalized) 포맷으로 변환한다. 공통 포맷은 본질적으로 모든 지원되는 포맷의 수퍼세트이다. 공통 포맷을 사용하는 이점 중 하나는 포맷 인식(format-aware) 애플리케이션이 이제 하나의 포맷 - 공통 포맷 - 만을 인식할 필요가 있다는 것이다. 또한, 공통 포맷으로 변환된 콘텐트를 관리하면, 플랫폼은 수개의 포맷이 아니라 단지 하나의 포맷에만 관여하면 되기 때문에 훨씬 수월하다. 또한, 장래에 추가적인 신디케이션 포맷이 개발될 때, 피드 포맷 모듈은 그 포맷을 다루도록 적응될 수 있는 동시에, 애플리케이션이 새로운 포맷을 완전히 인식하지는 못하더라도 새로운 포맷을 통해 플랫폼에 도달하는 콘텐트를 사용할 수 있게 해준다.

공통 포맷과 관련하여, 이하를 고려한다. 포맷 관점에서, 공통 포맷은 상이한 포맷 간에 공통적인 XML 스키마(schema)에 의해 표시된다. 상이한 포맷에서는, 어떤 구성 요소는 XML 포맷의 계층 구조 내에서의 상이한 이름, 상이한 위치 등을 가질 수 있다. 따라서, 공통 포맷은 가능한 모든 상이한 포맷으로부터 총체적으로 나오는 공통 구조와 구문을 나타내는 것에 관한 것이다. 따라서, 일부 예에서는, 하나의 포맷으로부터의 구성 요소가 공통 포맷의 구성 요소로 매핑(mapping)될 수 있다.

피드 스케쥴 모듈 -- 302

각 피드는, 이용가능한 새로운 콘텐트의 존재 여부를 확인하기 위하여 동기화 엔진(108)이 언제 체크해야 하는 지에 대한 그 고유의 스케쥴을 가질 수 있다. 따라서, 동기화 엔진은 피드 스케쥴 모듈(302)을 통해, 사이트뿐만 아니라 사용자 또는 시스템의 요구사항 및 제한 사항을 존중하기 위해 이러한 스케쥴을 관리한다.

예로서, 이하를 고려한다. 피드가 처음 다운로드될 때, 갱신 스케쥴(즉, 피드가 언제 갱신될지에 관한 스케쥴)이 피드의 헤더에 포함될 수 있다. 이 경우, 피드 스케쥴 모듈(302)은 이 특정한 피드를 위해 갱신 스케쥴을 유지하고, 그 갱신 스케쥴에 따라 새로운 콘텐트가 있는지를 체크한다. 그러나, 스케쥴 정보가 포함되어 있지 않으면, 피드 스케쥴 모듈은 새로운 콘텐트가 있는지를 체크하기 위하여 디폴트 스케쥴을 사용할 수 있다. 예컨대 24시간마다 피드 콘텐트를 재다운로드하는 것과 같은 임의의 적절한 디폴트 스케쥴이 사용될 수 있다. 적어도 일부 실시예에서, 사용자는 상이한 디폴트 작업 스케쥴을 특정할 수 있다.

또한, 적어도 일부 실시예에서, 피드 스케쥴 모듈은 최소 스케쥴( minium schedule)로서 칭해지는 것을 지원할 수 있다. 최소 스케쥴은 갱신 사이의 기간을 규정하는 최소 갱신 시간을 말한다. 즉, 플랫폼은 최소 스케쥴이 규정하는 것보다 빈번하게 피드를 갱신하지는 않는다. 적어도 일부 실시예에서, 사용자는 최소 시간을 변경할 수 있다. 또한, 사용자는 임의의 또는 모든 피드의 수동 리프레시를 개시할 수도 있다.

디폴트 및 최소 스케쥴을 지원하는 것 외에, 적어도 일부 실시예에서는, 피드 스케쥴 모듈이 게시자-특정 스케쥴( publisher - specified schedules)을 지원할 수 있다. 이름이 암시하는 바와 같이, 게시자-특정 스케쥴은 특정한 게시자에 의해 특정되는 스케쥴이다. 예컨대, 게시자-특정 스케쥴은 통상적으로 클라이언트가 피드를 다음 번 갱신해야 할 때까지 몇 분이 걸릴지를 특정할 수 있다. 이는 RSS 0.9x/2.0 "ttl" 구성 요소를 사용하여 특정될 수 있다. 동기화 엔진은 적어도 그 몇 분이 경과할 때까지는 피드의 새로운 사본을 페치해서는 안된다. 게시자-특정 스케쥴은 또한 시간, 일, 주 등과 같은 단위의 상이한 레벨로 특정될 수 있다.

단, 피드 문서의 각 사본은 상이한 게시자-특정 스케쥴을 가질 수 있다. 예컨대, 낮 동안에는, 게시자가 15분의 스케쥴을 제공할 수 있고, 그 후 밤에는, 게시자가 1시간의 스케쥴을 제공할 수 있다. 이 경우, 동기화 엔진은 피드가 다운로드될 때마다 그 행동을 갱신한다.

또한, 적어도 일부 실시예에서, 동기화 엔진은 피드 스케쥴 모듈(302)을 통해 몇 시간 및/또는 몇 일을 스킵(skip)하는 개념을 지원한다. 구체적으로, RSS 0.9 및 2.0은 클라이언트가 갱신 동작을 하지 않아야 하는 몇 일 또는 몇 시간 동 안 서버를 차단하게 할 수 있다. 이 경우, 동기화 엔진은, 서버에 의해 제공되면, 이들 설정을 존중하고, 그 시간 동안에는 피드를 갱신하지 않는다.

적어도 일부 실시예에서는, 디폴트 스케쥴, 최소 스케쥴 및 게시자 특정 스케쥴 외에, 동기화 엔진이 사용자 특정 스케쥴 및 수동 갱신의 개념을 지원한다. 보다 구체적으로는, 사용자는 피드 별로 자신이 선택한 스케쥴을 특정할 수 있다. 플랫폼 관점으로부터, 사용자 특정 스케쥴은 서버에 의해 특정되는 만큼 복잡할 수 있다. 이 예에서, 플랫폼은, 피드 스케쥴 모듈을 통해, 피드로부터 추출되는 가장 최근의 스케쥴뿐만 아니라 사용자 스케쥴을 유지한다. 적어도 일부 실시예에서, 사용자 스케쥴은 항상 게시자의 스케쥴에 우선한다. 또한, 언제라도, 애플리케이션은 모든 피드 또는 개개의 피드의 강제 갱신을 개시할 수 있다.

대역폭 및 서버 고려 사항에 관하여, 이하를 고려한다. 일 실시예에 의하면, 동기화 엔진은 2개의 관련 이슈의 관점에서 설계될 수 있다. 첫째, 동기화는 사용자의 대역폭 및 CPU를 이해하여야 한다. 둘째, RSS 플랫폼의 폭넓은 사용 때문에, 동기화 엔진은 그것이 서버에 미치는 영향을 이해하여야 한다. 이들 2개의 이슈는 피드가 다운로드되는 시기 및 방법에 영향을 미친다.

피드가 다운로드되는 시기의 관점으로부터, 동기화 엔진은 이하의 고려 사항을 염두에 두고 설계될 수 있다. 서버로부터의 스케쥴, 및 사용자로부터의 어떤 다른 명령이 없을 때, 동기화 엔진은 갱신되는 빈도에 매우 보존적이어야 한다. 따라서, 적어도 일부 실시예에서는, 디폴트 스케쥴이 24시간으로 설정된다. 또한, 사용자의 리소스가 비능률적인 서버에 의해 악영향을 받는 것을 방지하기 위하여, 동기화 엔진이 너무 자주 갱신되는 것을 막도록, 심지어는 서버가 다른 경우를 특정하였더라도, 최소 스케쥴이 강제될 수 있다. 또한, 로그인 시간(및 공통 인터벌, 예컨대 시동 시간으로부터 매 시간)의 갱신이 주의깊게 관리되어야 한다. 피드 갱신은 사용자 로그인이 완료된 후의 특정 기간까지 지연되어야 하고, 각 시간마다 발생되는 많은 양의 갱신을 피하기 위하여 그 시간에 약간의 시차를 두어야 한다. 이는 한번에 모든 갱신을 발생시키려는 사용자의 희망과는 반대로 균형이 맞춰질 수 있다. 또한, 서버가 위에서 설명된 시간 스킵 또는 일 스킵 특징을 사용할 때, 클라이언트는 그러한 일시적 정지(moratorium) 기간이 끝나자마자 즉각 갱신을 페치해서는 안된다. 대신에, 클라이언트는 콘텐트를 페치하기 전에, 15분까지의 범위 내의 랜덤 인터벌을 대기하여야 한다.

이와 관련하여 동기화 엔진을 돕기 위하여, 피드 스케쥴 모듈(302)은 각 피드마다 프레시(fresh) 또는 스테일(stale)과 같은 상태를 유지할 수 있다. "프레시" 상태란, 게시자 스케쥴에 기초하여, 피드가 프레시된 것을 의미한다. "스테일" 상태란, 게시자의 스케쥴은 갱신을 나타냈지만, 동기화 엔진이 아직 갱신을 완료하지 못한 것을 의미한다. 가장 프레시한 콘텐트에 관심이 있는 클라이언트는 즉각적인 갱신을 요청할 수 있고, 갱신이 이용가능한 때를 통지받을 수 있다. 이 기대가 설정되면, 동기화 엔진은, 사용자 및 서버에게 손해를 주면서까지 엄격하게 스케쥴을 따라가기 보다는, 콘테트를 갱신할 때 임의적인 지연을 구현할 수 있다.

피드가 다운로드되는 방법과 관련하여, 이하를 고려한다. 일 실시예에서, 동기화 엔진은 미리 정해진 시간에 동기화 엔진 프로세스를 런칭하기 위하여 태스 크 스케쥴러를 사용할 수 있다. 동기화 엔진이 완료된 후에는, 동기화 엔진을 다시 런칭해야 하는 다음 시간(즉, NextSyncEngineLaunchTime)으로 태스크 스케쥴을 갱신한다.

동기화 엔진이 런칭될 때는, NextUpdateTime이 currentTime 이하인 모든 "계류중인(pending)" 피드를 큐(queue)한 후, 이하와 같이 처리한다. 각 피드에 대해서는, LastUpdateTime, NextUpdateTime, Interval(분 단위로 특정됨) 및 LastErrorInterval과 같은 속성이 트래킹된다.

피드의 성공적인 동기화의 마지막에는, 피드의 LastUpdateTime은 현재 시간으로 설정되고, NextUpdateTime은 LastUpdateTime 더하기 인터벌 더하기 랜덤성(randomness)(인터벌의 1/10)으로 설정된다. 구체적으로는,

이다.

Random(argument)는 0과 그 인수(argument) 사이의 양의 값으로 정의된다. 예컨대, Random(10)은 0과 10 사이에서 부동(floating)된다.

피드의 동기화가,

HTTP 4xx 응답 코드;

HTTP 5xx 응답 코드;

Winsock/network 에러; 또는

HTTP 200, 그러나 응답 본문은 구문 분석 에러를 포함함(인식되는 피드 포맷 이 아님)

과 같은 이유 중 하나로 인해 실패했다면, 익스포넨셜 백 오프 알고리즘(exponential back off algorithm)이 이하와 같이 적용된다.

모든 "계류중인" 피드의 동기화가 완료된 후에, 동기화 엔진은 NextUpdateTime이 경과한(NextUpdateTime <= currentTime) 임의의 피드가 존재하는지 여부를 판정한다. 만약 존재한다면, 동기화 엔진이 막 런칭된 것처럼 이들 "계류중인" 피드가 큐되고 처리된다.

완료되지 않은 "계류중인" 피드가 존재하지 않으면, 동기화 엔진은 NextUpdateTime이 현재 시간에서 2분 내에 있는(currentTime + 2min >= NextUpdte Time) "곧 동기화 되려는(soon-to-sync)" 임의의 피드가 존재하는지 여부를 판정한다. "곧 동기화 되려는" 임의의 피드가 존재하면, 동기화 엔진 프로세스는 계속하여 실행되고, 타이머를 NextUpdateTime에서 "웨이크 업(wake up)"으로 설정하고, "계류중인" 피드를 처리한다.

만약 "곧 동기화 되려는" 피드가 존재하지 않으면, NextSyncEngineLaunch가 가장 빠른 NextUpdateTime을 갖는 피드의 NextUpdateTime으로 설정된다. 그 후, 태스크 스케쥴러가 NextSyncEngineLaunchTime으로 설정되고, 동기화 엔진 프로세스는 종료된다.

일 실시예에 의하면, 큐에 몇몇의 "계류중인" 피드가 존재하는 경우, 동기화 엔진은 복수의 피드를 병렬적으로 동기화할 수 있다. 그러나, 네트워크 대역폭 및 프로세서 사용이 과도해지지 않게 하기 위해서는, 병렬 동기화의 수뿐만 아니라, 어떤 시간 내에서 행해지는 동기화의 수도 제한되어야 한다. 일 실시예에 의하면, 피드 동기화 형성(shaping)은 토큰 버킷(token-bucket)을 통해 제공된다. 개념상, 토큰 버킷은 이하와 같이 동작한다.

● 1/r초마다 토큰이 버킷에 추가되고,

● 버킷은 최대 b 토큰을 유지할 수 있고, 만약 버킷이 꽉 찼을 때 토큰이 도달하면, 그 토큰은 폐기되고,

● 피드가 동기화될 필요가 있을 때, 토큰이 버킷으로부터 제거되고, 피드가 동기화되며,

● 어떠한 토큰도 이용가능하지 않으면, 피드는 큐에 머물고, 토큰이 이용가능해질 때까지 대기한다.

이러한 방식은 b 피드까지의 피드 동기화의 버스트를 허용한다. 그러나, 장기적으로는, 동기화가 일정한 레이트 r로 제한된다. 구현 예에서, 동기화 엔진은 b = 4 및 r = 2의 값을 사용한다.

피드 콘텐트 다운로드 모듈 -- 304

일 실시예에 의하면, 피드 콘텐트 다운로드 모듈(304)은 피드를 다운로드하고, 기존의 피드 데이터와 새로운 피드 아이템을 합하는 프로세스를 다룬다.

피드 콘텐트 다운로드 모듈을 구현할 수 있는 방법의 예로서, 이하를 고려한 다. 적절한 시간에, 동기화 엔진은 피드 콘텐트 다운로드 모듈을 통해 서버에 접속하고, 적절한 콘텐트를 다운로드한다.

일 실시예에 의하면, 플랫폼은 콘텐트를 다운로드하기 위하여 상이한 프로토콜들을 지원하도록 구성된다. 예컨대, 동기화 엔진은 HTTP를 통한 피드 문서의 다운로드를 지원할 수 있다. 또한, 동기화 엔진은 암호화된 HTTP URL(예컨대, SSL, http 등)을 지원할 수 있다. 마찬가지로, 동기화 엔진은 HTTP gzip 지원을 사용하는 압축을 지원할 수도 있고, UNC(Universal Naming Convention) 공유로부터의 피드 다운로드를 지원할 수도 있다.

또한, 동기화 엔진은 피드 콘텐트 다운로드 모듈을 통해 여러 유형의 인증을 지원할 수 있다. 예컨대, 동기화 엔진은 각 피드마다 사용자 이름/비밀 번호를 저장할 수 있고, 피드 문서를 리트리브(retrieve)하기 위하여 HTTP 기본 인증을 위해 이 사용자 이름/비밀 번호를 사용할 수 있다.

피드 갱신과 관련하여, 이하를 고려한다. 피드가 새로운 콘텐트를 갖는지 여부를 판정하기 위하여, 동기화 엔진은 각 피드마다,

● HTTP 응답에서 Last-modified 헤더에 의해 기록된, 피드가 갱신된 마지막 시간;

● 마지막 HTTP 응답에서 Etag 헤더의 값; 및

● 피드에 있어서 가장 최근의 pubDate 값(즉, 피드 레벨의 게시 날짜와 시간)

과 같은 정보의 단편들을 유지한다.

사이트가 Etag 또는 Last-modified를 지원하면, 동기화 엔진은 이들을 사용하여 새로운 콘텐트의 존재 여부를 체크할 수 있다. 이 사이트는 새로운 콘텐트가 없다는 것을 나타내기 위하여 HTTP 응답 코드 304로 응답할 수 있다. 그렇지 않으면, 콘텐트가 다운로드된다. 예컨대, 사이트가 피드용 RFC 3229(RFC 3229-for-feeds)를 지원하면, 클라이언트가 전달한 Etag에 기초하여, 사이트는 새로운 콘텐트만을 복귀시킬 수 있다. 어차피, 그 후에 클라이언트는 저장된 콘텐트와 새로운 콘텐트를 합친다.

피드 콘텐트가 다운로드될 수 있는 방법을 단지 하나의 구현예로 상술하기 위해, 이하를 고려한다. 특정한 사이트가 변경되었는지 여부를 판정하기 위하여, 동기화 엔진은,

● 클라이언트가 저장된 Etag를 갖는 경우는, If - None - Match 헤더;

○ 피드, gzip 값을 갖는 헤더 A-IM(피드용 RFC 3229에서 사용됨)

● 클라이언트가 저장된 Last-modified 값을 가지면, If - Modified - Since 헤더

를 이용하여 요청을 전송할 것이다.

서버가 HTTP 응답 코드 304로 응답하면, 콘텐트는 변화되지 않은 것이고, 프로세스는 여기서 종료된다. 서버가 콘텐트(즉, HTTP 코드 200 또는 206으로 응답하면, 다운로드된 콘텐트는 로컬 콘텐트와 합쳐진다(단, 코드 206은 서버가 피드용 RFC 3229를 지원하고, 다운로드된 콘텐트는 새로운 콘텐트뿐임을 의미한다).

이용가능한 콘텐트가 존재하고, 동기화 엔진이 저장된 pubDate를 갖고, 다운 로드된 피드 문서가 채널 레벨 pubDate 구성 요소를 포함하면, 2개의 날짜가 비교된다. 다운로드된 pubDate와 로컬 pubDate가 동일하면, 콘텐트는 갱신되지 않았다. 그러면, 다운로드된 피드 문서는 폐기될 수 있다.

동기화 엔진이 한번에 하나씩 각 아이템을 처리하면, 각 아이템의 pubDate는 (만약 있다면) 동기화 엔진이 저장한 pubDate와 비교되고, 더 오래된 아이템은 폐기된다. 그 후, 각 아이템은 저장부의 아이템과 비교된다. 비교는, 만약 guid 구성 요소가 존재한다면 이를 사용해야 하고, 아니면 guid 구성 요소가 존재하지 않으면 링크 구성 요소를 사용해야 한다. 일치가 발견되면, 새로운 아이템의 콘텐트는 오래된 아이템의 콘텐트를 대체한다(만약 둘다 pubDate를 가지면, 어느 것이 더욱 새로운 것인지를 판정하는데 사용되고, 그렇지 않으면 가장 최근에 다운로드된 것이 새로운 것이다). 일치가 발견되지 않으면, 저장된 피드 콘텐트보다 새로운 아이템이 앞에 나와야 한다("가장 최근의 것이 맨 위에(most recent at the top)"란 의미). 임의의 아이템이 로컬 피드에 추가되거나 갱신되면, 피드가 갱신된 것으로 간주되고, RSS 플랫폼의 클라이언트에게 통지된다.

에러의 경우에 있어서는, 이하를 고려한다. 서버가 코드 500 또는 대부분 400 에러로 응답하면, 동기화 스케쥴이 리셋되고, 서버는 후에 다시 시도한다. 그러나, HTTP 에러 410은 갱신 스케쥴을 "더 이상의 갱신은 없음(no more updates)"으로 리셋하기 위한 표시로서 취급되어야 한다.

HTTP 레벨 리디렉트(redirect)가 이어져야 하지만, 클라이언트 구성에는 어떠한 변화도 행해지지 않는다(리디렉트가 우연히 주어지는 몇몇의 병적인 시나리오 가 있다).

서버가 XML 리디렉트로 응답하면, 피드는 리디렉트되어야 하고, 피드에 저장된 URL은 자동 갱신되어야 한다. 이는 클라이언트가 피드 URL을 자동으로 갱신하는 유일한 경우이다.

피드의 다운로드와 관련하여, 사용자가 다른 태스크에 몰두하고 있을 때, 다운로드는 기계의 일상적인 사용(예컨대, 대역폭 또는 CPU)을 방해해서는 안된다. 또한, 콘텐트에 의존하는 상호작용 애플리케이션의 경우, 사용자는 가능한 한 빨리 콘텐트를 얻을 수 있어야 한다.

인클로저 다운로드 모듈 -- 306

일 실시예에 의하면, 인클로저 다운로드 모듈(306)은 피드를 위하여 인클로저 파일을 다운로드하고, 적절한 보안 영역을 적용할 책임이 있다. 피드 콘텐트를 다운로드할 때, 인클로저 또한 다운로드된다.

인클로저의 다운로드는 몇 가지 상이한 방식으로 다루어질 수 있다. 우선, 기본 인클로저(basic enclosure)는 RSS 2.0 스타일 인클로저인 것이 고려된다. 기본 인클로저에 있어서, 동기화 엔진은 인클로저 다운로드 모듈(306)을 통해, 인클로저 링크를 찾기 위하여, 다운로드된 피드를 자동으로 구문 분석할 것이다. 동기화 엔진은 복수의 기본 인클로저를 지원하도록 구성된다. 인클로저 다운로드 모듈은 그 후 인클로저 링크를 사용하여 인클로저를 다운로드할 수 있다. 적어도 일부 실시에에서, 어떤 새로운 피드에 대해서는, 디폴트 동작이 기본 인클로저를 다운로 드하지 않는 것이다. 상술한 객체 모델을 노출시키는 API를 사용하면, 클라이언트는 예컨대 항상 인클로저를 다운로드하거나 특정 피드의 특정 아이템의 특정 인클로저의 다운로드를 강제하도록, 피드별로 행동을 변화시키는 것 등을 할 수 있다.

강화된 인클로저의 취급은 상술된 공통 포맷의 사용을 통해 제공될 수 있다. 구체적으로는, 적어도 일 실시예에서, 공통 포맷은 인클로저를 위한 추가적인 기능을 정의한다. 구체적으로, 공통 포맷은 특정 단편의 콘텐트를 복수 개로 표현할 수 있게 한다. 예컨대, 이는 프리뷰(preview) 콘텐트 및 디폴트 콘텐트의 표준 정의뿐만 아니라, 인클로저가 다운로드되어야 하는지 아니면 스트림되어야 하는지 여부를 나타내는 능력을 포함한다. 또한, 공통 포맷은 인클로저 및 콘텐트의 표현에 임의적인 메타데이터를 허용한다. 어떤 새로운 피드에 대하여, 디폴트 동작은 예컨대 아이템당 10k의 디폴트 사이즈 제한을 따르는 임의의 인클로저의 "프리뷰" 버전을 다운로드하는 것이다.

API를 사용하면, 클라이언트는 피드별로 행동을 변화시키는 것 등을 할 수 있다. 예컨대, 행동은 피드의 아이템의 "디폴트" 버전을 항상 다운로드하도록, 또는 특정한 값의 메타데이터 구성 요소를 갖는 임의의 특정한 버전을 항상 다운로드하도록 변화될 수 있다. 이는 예컨대, 각 인클로저마다 "이것을 다운로드할까요?"를 제공하는 클라이언트 콜백을 이용하여 행해질 수 있다. 또한, API를 사용하면, 클라이언트는 특정 피드의 어떤 특정 아이템(또는 모든 아이템)의 어떤 특정 인클로저의 어떤 특정 표현의 즉각적인 다운로드를 강제할 수 있다.

인클로저 다운로드 프로세스에 보안을 제공하는 것과 관련하여, 이하를 고려 한다.

일 실시예에 의하면, 다운로드된 인클로저는 윈도우즈 XP SP2 AES(Attachment Execution Service) 기능을 사용한다. 이 기능은 파일 유형 및 영역 기반 보안을 제공할 수 있다. 예컨대, (인클로저가 나온) 파일 이름 및 영역 정보가 제공되었다면, AES는 차단(block), 허용(allow) 또는 프롬프트(prompt) 여부를 나타낼 수 있다.

영역 영속성과 관련하여, 파일을 저장할 때, AES가 영역 정보를 영속시켜, 나중에 그것이 열릴 때, 사용자가 프롬프트를 제공받을 수 있게 한다.

이하의 표 1은 AES 위험-레벨/영역 대 동작 매핑을 도시한다.

위험 레벨	제한	인터넷	인트라넷	로컬	신뢰
위험 예컨대, EXE	차단	프롬프트	허용	허용	허용
보통/알려지지 않음 예컨대, DOC 또는 FOO	프롬프트	프롬프트	허용	허용	허용
낮음 예컨대, TXT 또는 JPG	허용	허용	허용	허용	허용

도시되고 설명되는 실시예에서, 동기화 엔진은 예컨대 다운로드되는 각 인클로저마다 메소드, 예컨대 CheckPolicy 메소드를 호출할 수 있다. 응답에 기초하여, 동기화 엔진은,

● 차단 : 저장 안하기(이는 피드 파일에 실패로 표시됨)

● 허용 : 인클로저 저장하기

● 프롬프트 : 저장하지만, 영역 정보를 영속시킴 - 이는 사용자가 파일을 더블 클릭하면, "실행/비실행(Run/Don't Run)" 프롬프트를 제공받게 됨을 의미함 -

중 하나를 행할 수 있다.

일 실시예에 의하면, 동기화 엔진은 우선 인클로저를 디스크에 저장하고, 인클로저를 메모리에 다운로드하지는 않을 것이다. 디스크에 저장하면 필터 기반형 안티바이러스 애플리케이션을 트리거하고, 애플리케이션이 선택되면 이들 애플리케이션에 인클로저를 검역(quarantine)할 기회를 부여한다.

아카이빙 모듈 -- 308

일 실시예에 의하면, 아카이빙 모듈(308)은 오래된 피드 데이터를 처리할 책임이 있다. 디폴트에 의하여, 피드는 최대 200개의 아이템을 유지할 것이다. 피드가 특정된 최대치를 넘으면, 아카이빙 모듈에 의하여 이전의 피드 아이템이 삭제된다. 그러나, 연관된 인클로저들은 삭제되지 않는다.

피드 저장부

일 실시예에 의하면, 피드 저장부(112)(도 1)는 2가지 유형의 정보 - 피드 리스트(114) 및 피드 데이터(116) -를 유지한다. 예로서, 도 4를 고려한다. 거기서, 피드 리스트(114)는 피드의 리스트의 계층적인 트리 구조(400)로서 구현된다. 피드 데이터(116)는 특정 피드와 연관된 데이터를 포함한다. 이 예에서, 피드 데이터(116)는 아이템 및 인클로저의 콜렉션(402)을 포함하기 위하여 피드별로 배치된다.

피드 저장부를 구현할 수 있는 여러가지 상이한 방식이 있다. 이 특정 구현예서는, 피드 저장부가 파일 시스템의 일부를 포함한다. 이에 대한 한가지 이유는 간략화 때문이다. 즉, 이 실시예에서, 피드 리스트는 정규의 디렉토리로서 간단히 표시되며, 그 아래에는 서브디렉토리 및 파일이 있을 수 있다. 계층 구조는 기본 파일 시스템 계층 구조로서 반영된다. 따라서, "뉴스" 및 "블로그"와 같은 각 폴더는 본질적으로 서브디렉토리 및 파일을 갖는 파일 시스템 내의 정규의 디렉토리이다.

이 특정 예에는, 피드 구독을 나타내는 특정한 파일 유형이 있다. 단지 예로서, 이러한 유형의 파일이 "xyz.stg" 포맷을 갖는 것을 고려한다. .stg 파일은 피드를 위한 모든 데이터를 저장한다. 따라서, 사용자는 트리 구조(400)로 구현된 리스트와 같은 피드 리스트를 갖고, 각 피드(또는 파일) 내에는 피드 데이터가 존재한다.

도시되고 설명되는 실시예에서, .stg 파일은 구조화된 저장( structured storage) 기술을 이용하여 구현된다. 구조화된 저장 기술은 공지되어 있고, 당업자에 의해 이해될 것이다. 그러나, 간단한 배경 지식은 이하와 같다.

구조화된 저장은 단일 파일을 저장과 스트림으로 알려진 객체의 구조화된 콜렉션으로서 취급함으로써, COM에 파일 및 데이터의 영구성을 제공한다. 구조화된 저장의 목적은 상이한 파일에 별개의 객체 부분들을 저장하는 것과 연관된 오버헤드 및 실행 패널티를 감소시키는 것이다. 구조화된 저장은 복합 파일( compound file)이라고 칭하는 표준 구현을 통해 2가지 유형의 객체 - 저장과 스트림 -의 구조화된 콜렉션으로서 단일 파일 엔터티를 다루는 방법을 정의함으로써 해결책을 제공한다. 이에 의해, 마치 별개의 객체들의 네스티드(nested) 계층 구조가 아니라 단일 파일인 것처럼, 사용자가 복합 파일과 상호작용할 수 있고, 복합 파일을 관리할 수 있다. 저장 객체 및 스트림 객체는 당업자에 의해 이해되는 바와 같이, 파일 내의 파일 시스템으로서 기능한다. 구조화된 저장은, 새로운 객체가 복합 파일에 추가되거나 기존의 객체의 사이즈가 증가할 때마다, 저장 장치에 파일을 전부 재기입할 필요성을 제거함으로써 실행 문제를 해결한다. 새로운 데이터는 영구적인 저장 장치에서 다음의 이용가능한 위치에 기입되고, 저장 객체는 그 저장 객체 및 스트림 객체의 위치의 트래킹을 유지하는, 포인터의 테이블을 갱신한다.

따라서, 도시되고 설명되는 실시예에서, .stg 파일은 구조화된 저장 기술을 이용하여 구현되고, 피드 저장부의 맨 위에 있는 API는 상이한 스트림 및 저장에 대한 액세스를 허용한다. 이 특정 예에서, 각 RSS 아이템은 하나의 스트림 내에 기입된다. 또한, 헤더 스트림은 명칭, 구독, 피드 URL 등과 같은 특정 피드와 연관된 정보를 포함한다. 또한, 다른 스트림은, 신속하게 어떤 것을 판독/비판독으로서 표시하는 것, 아이템을 삭제하는 것을 비롯한 목적으로, 파일의 콘텐트에 빠르고 효율적인 액세스를 허용하는 인덱스 유형의 메타데이터를 저장한다.

파일 시스템 -- 인클로저

도시되고 설명되는 실시예에서, 인클로저는 도 1에 도시된 바와 같이 피드 데이터의 일부로서 또는 구조화된 저장으로 저장되지 않는다. 오히려, 인클로저는 다른 애플리케이션과 사용자가 액세스하고 조작하고 싶어할 수 있는 사진 또는 사진들과 같은 아이템인 것으로 인식된다.

따라서, 도시되고 설명되는 실시예에서, 인클로저는 사용자의 특정 프로필에 기입된다. 그러나, 연관된 피드 아이템과 인클로저 사이의 링크는 유지된다.

예로서, 도 5를 고려한다. 사용자가 피드를 구독하기 시작하면, 피드 콘텐트는 사용자의 프로필 아래에서 애플리케이션 데이터(Application Data) 또는 알려진 폴더(Knownfolder) "피드(feeds)" 중 어느 하나에 국부적으로 저장된다.

피드리스트 및 피드는 피드 리스트 및 피드의 포맷을 양호하게 제어할 수 있도록 애플리케이션 데이터에 저장된다. API는 애플리케이션이 피드를 액세스하고 관리할 수 있도록 (이하 기술되는 바와 같이) 노출된다.

피드리스트는 사용자가 구독하는 피드의 세트이다. 이 예에서, 피드 리스트를 포함하는 파일은,

에 위치한다.

파일은 피드의 속성뿐만 아니라, 아이템 및 인클로저의 속성(아이템에 연관된 파일에 대한 URL)도 포함한다. 예컨대, 피드 "NYT"를 위한 파일은,

에 위치한다.

이 예에서, 인클로저는 피드에 의해 그룹 지어지고, 알려진 폴더 "피드"에 저장된다. 이에 의해 사용자와 다른 애플리케이션이 다운로드된 파일을 용이하게 액세스하고 사용할 수 있다.

예컨대, 사용자는 NPR 피드를 구독하고, 사용자의 미디어 플레이어 애플리케이션이 자동으로 파일을 추가할 수 있음을 확실히 하고 싶어한다. 이 알려진 폴더를 만들면, 사용자가 미디어 플레이어로부터 알려진 폴더에 브라우징할 수 있고, 이를 모니터되는 폴더로서 설정할 수 있다. 연관된 포스트 및 피드에 애플리케이션이 액세스할 수 있도록, 인클로저는 그 피드 및 포스트의 적절한 메타데이터를 갖는다. 포스팅한 인클로저는,

에 위치한다.

사용자의 하드 디스크에 기입되는 각 인클로저는 이 인클로저에 대한 메타데이터를 포함하는 2차 스트림(예컨대, NTFS 스트림)을 가질 것이다. 메타데이터는 예로서 인클로저가 나오는 피드, 저자, 피드 아이템으로의 링크, 설명, 명칭, 게시 날짜 및 다운로드 날짜뿐만 아니라 적절한 다른 메타 데이터를 포함할 수 있지만, 이에 한정되지 않는다.

게시 엔진/포스트 큐

우리가 일상적인 블로그 포스트를 기입하는 많은 때에, 본질적으로 기입되고 있는 것은 RSS 아이템이다. 이 RSS 아이템은 통상적으로 소정 유형의 서버로 전송되고, 이 서버는 계정 정보, 블로그의 위치 등을 유지한다. 이 콘텍스트에서, 게시 엔진(110)(도 1)은 애플리케이션이 콘텐트를 포스팅하거나 콘텐트를 게시할 수 있도록 구성되는 동시에, 서버와 통신하는 데 사용되는 통신 프로토콜을 애플리케이션으로부터 무시한다. 따라서, 애플리케이션은 포스팅될 콘텐트 또는 데이터를 제공하기만 하면 되고, 게시 엔진이 콘텐트를 포맷하고 적절한 서버에 송신하는 나머지 태스크를 다룰 것이다.

몇몇의 상이한 프로토콜이 사용될 수 있음에 따라, 여러 상이한 유형의 애플리케이션들이 게시 기능을 사용할 수 있는 한, 애플리케이션으로부터 프로토콜을 무시하면 상당한 융통성이 생긴다. 도시되고 설명되는 실시예에서는, 게시 엔진의 기능은, 서버와 통신하는 데 사용되는 프로토콜을 알 필요 없이, 애플리케이션이 블로그를 포스팅할 수 있게 하는 API로서 구현된다.

따라서, 이 예에서, API는, 호출될 때 RSSItem 객체를 생성하는 새로운 포스트를 생성하는 메소드를 갖는다. 이 RSSItem 객체는 호출될 때 콘텐트 - 이 경우에는, 블로그 - 를 임시 저장부(temporary store), 즉 포스트 큐(122)(도 1)에 저장하는 포스트 메소드를 갖는다. 블로그가 생성될 때 사용자가 온라인 상에 없을 수 있기 때문에, 콘텐트는 임시 저장부에 저장된다. 그러면, 사용자가 온라인 접속을 행할 때, 게시 엔진(110)이 적절한 서버에 접속을 행하고, 서버에 블로그를 업로드하기 위하여 서버의 적절한 프로토콜을 사용한다.

구현 예

이하의 설명에서는, 예시적인 API들의 세트는 상술한 기능을 구현하기 위하여 API를 구현하고 구조화하는 방법의 일례만을 제공하기 위해 기술된다. 청구 대상의 정신과 범위를 벗어나지 않고도 다른 API가 사용될 수 있음이 이해될 것이다. 설명되는 API는 통상적으로 컴퓨터 판독가능 명령어 및 소정 유형의 컴퓨터 판독가능 매체에 상주하는 데이터로서 구현된다.

이하에서 설명되는 API는 사용자가 구독하는 피드의 세트(System Feed List) 및 피드의 속성을 조작하는데 사용될 수 있다. 또한, 피드 데이터 API(즉, 아이템 및 인클로저)는 피드 저장부에 저장되는 피드에 대한 액세스 및 피드의 애드혹 다운로드를 제공한다. 피드 API를 사용하면, 웹 브라우저, 미디어 플레이어, 디지털 이미지 라이브러리 애플리케이션 등과 같은 애플리케이션이 그들의 경험 내에서 피드 데이터를 노출시킬 수 있다.

설명하려고 하는 예에서, API는 스크립트 언어, 관리 코드뿐만 아니라 네이티브 Win32(C++) 코드로부터도 API를 이용가능하게 하는 COM 듀얼 인터페이스로서 구현된다.

도 6은 일 실시예에 따라 상위 레벨 객체 또는 인터페이스인 IFeed 및 IFeedFolder 객체 또는 인터페이스를, 연관된 속성, 메소드 및 이벤트와 함께 도시한다.

이 예에서, IFeed는 하나의 속성 - IFeedFolder인 구독 - 을 갖는다. 이는 모든 구독을 위한 루트 폴더이다. DeleteFeed(), DeleteFeedByGuid(), DeleteFolder() 등과 같이 루트 객체에 대한 많은 메소드가 있다.

이 예에서는 GetFeedByGuid() 메소드에 관심이 있다. 이 메소드는 특정한 피드를 예컨대, 피드의 GUID에 의해 액세스하기 위하여 애플리케이션에 의해 호출될 수 있다. 따라서, 애플리케이션은 피드의 계층적인 순서화를 인식가능할 필요가 없다. 오히려, 피드의 GUID는 플랫폼이 피드를 페치할 수 있도록 애플리케이션에 의해 사용될 수 있다.

또한, ExistFeed() 메소드는 피드의 존재를 이름에 의해 체크하고, ExistFeedByGuid()는 피드의 존재를 GUID에 의해 체크한다. GetFeed() 메소드는 피드를 이름 또는 GUID에 의해 얻는다. IsSubscribed() 메소드는 애플리케이션 또는 호출자가 특정한 피드가 구독되었는지 여부를 확인할 수 있게 한다.

또한, IFeed 객체는 또한 시스템 피드 리스트 상의 변화에 관한 통지에 대한 등록을 허용하는 SubscriptionsNotifications 이벤트를 갖는다.

위에서 언급된 바와 같이, Subscriptions는 IFeedFolder 유형이다. IFeedFolder 객체 또는 인터페이스는 본질적으로 디렉토리를 제공하고, 이름(Name), 부모(Parent), 경로(Path) 등과 같이 유사한 종류의 속성을 갖는다. 또한, IFeedFolder 객체는 IFeed 유형의 Feeds 속성 및 IFeedFolder 유형의 Subfolders 속성을 갖는다. Subfolders 속성은 인스턴트 폴더 아래의 폴더들의 콜렉션(예컨대, 이는 계층 구조가 나오는 곳임)에 관련되고, Feeds 속성은 특정 폴더의 실제 피드들에 관련된다. 또한, IFeedFolder는 폴더 내부에 어떤 것이 기입된 마지막 시간을 나타내는 LastWriteTime 속성을 갖는다. 이 속성은, 잠시 동안 실행되지 않고 있지만, 그럼에도 불구하고 피드 플랫폼을 주시하고 필요에 따라 동기화할 수 있도록 그 상태를 확인해야 하는 애플리케이션에 유용하다.

IFeedFolder에는 다수의 메소드가 있으며, 일부의 메소드는 피드의 생성(이는 시스템이 갖지 않은 피드를 생성하고, 이를 특정한 폴더에 추가함), 서브폴더의 생성, 폴더 또는 서브폴더의 삭제 등에 관련된다.

도 7은 일 실시예에 따른 추가적인 객체 및 이들과 연관된 메소드를 도시한다. 구체적으로는 IFeed, Item 및 IEnclosure 객체가 도시되어 있다.

우선, IFeed 객체부터 시작해서, 이하를 고려한다. 당업자에 의해 이해되는 바와 같이, 이 객체와 연관된 많은 속성들은 RSS 피드 그 자체로부터 나온 것, 예컨대, 명칭(Title), Url, 웹마스터(Webmaster), 스킵 시간(SkipHours), 스킵 일자(SkipDays), 관리 에디터(ManagingEditor), 홈페이지(Homepage), 이미지 URL(ImageURL) 등이다. 또한, 관심이 있는 다른 세트의 속성, 즉 피드의 일부인 아이템 전부를 갖는 콜렉션인 Items 속성 및 인클로저 전부가 기입되는 실제 디렉토리를 제공하는 LocalEnclosurePath 속성이 있다. 따라서, 애플리케이션에 있어서, LocalEnclosurePath 속성은 애플리케이션이 인클로저에 액세스하는 것을 매우 용이하게 한다.

또한, 이 객체는 특정 피드를 관리하는 데 사용되는 Delete() 및 Download()와 같은 소규모의 세트의 메소드를 지원한다. 또한, 이 객체는 XML() 메소드를 지원하고, 이에 의해 피드의 XML을 공통 포맷으로 복귀시킨다. XML 데이터는 피드의 신문 뷰(view)를 생성하는 것과 같은 일에 사용될 수 있다. Clone()은 구독되지 않는 피드의 사본을 복귀시킨다.

Item 객체로 이동하면, 이 객체는 정규의 RSS 구성 요소를 나타내는 속성들, 예컨대 설명(Description), URL, 명칭(Title), 저자(Author) 등의 세트를 갖는다. 또한, 연관된 실제 피드를 다시 포인팅하는 Parent 속성, 및 전체 아이템을 통해 반복해야 하는 것과 비교하여 애플리케이션이 Id를 조작할 수 있도록 하는 Id 속성이 있다. 또한, IEnclosure 유형의 아이템의 인클로저의 콜렉션인 Enclosures 속성이 있다. 또한, IsRead 속성에 의해 애플리케이션이 특정한 아이템이 판독되었는지의 여부를 나타낼 수 있게 한다.

Enclosure 객체로 이동하여, 이하를 고려한다. 이 객체는 Type 속성(예컨대, mp3) 및 특정한 인클로저의 길이를 설명하는 Length 속성을 포함하는 속성들을 갖는다. 또한, 특정 인클로저에는 LocalAbsolutePath가 있다. Download() 메소드는 개개의 인클로저가 애플리케이션에 의해 다운로드되고 사용될 수 있게 한다.

결어

위에서 설명한 웹 콘텐트 신디케이션 플랫폼은 인터넷으로부터 획득되는 콘텐트를 관리하고, 조직하며, 또한 그러한 콘텐트를 소비가능한 상태로 하는데 이용될 수 있다. 플랫폼은 웹 콘텐트를 획득하고 조직할 수 있고, 이러한 콘텐트를 상이한 유형의 많은 애플리케이션들이 소비할 수 있게 한다. 이들 애플리케이션은 특정 신디케이션 포맷을 반드시 이해할 수도 있고, 이해하지 못할 수도 있다. API는 애플리케이션과 사용자가 피드의 생성, 판독, 갱신, 삭제 등과 같은 여러 상이한 태스크를 용이하게 할 수 있게 하는 객체 모델을 노출시킨다. 또한, 플랫폼은 플랫폼으로 들어가는 피드 데이터의 이용가능성을 향상시키는 공통 포맷을 제공하기 위하여 특정 피드 포맷을 무시할 수 있다. 또한, 플랫폼은, 웹 피드를 통해 수신될 수 있는 인클로저를, 신디케이션 인식 애플리케이션과 신디케이션 비인식 애플리케이션 모두가 그 인클로저를 소비할 수 있게 하는 방식으로 처리하고 관리한다.

비록 본 발명은 구조적 특징 및/또는 방법론적인 단계에 특정한 언어로 기재되어 있지만, 첨부되는 청구항에서 정의되는 본 발명은 기재되는 특정한 특징 또는 단계에 반드시 한정될 필요가 없음을 이해할 것이다. 오히려, 특정한 특징 및 단계는 청구되는 발명을 구현하는 바람직한 형태로서 개시되어 있다.

Claims (20)

1. 하나 이상의 컴퓨터 판독가능 매체; 및

   콘텐트 신디케이션 플랫폼을 구현하는 상기 매체 상의 컴퓨터 판독가능 명령어

   를 포함하고,

   상기 콘텐트 신디케이션 플랫폼은,

   소스로부터 콘텐트를 획득하고, 상기 콘텐트를 신디케이션 인식(syndication-aware) 애플리케이션과 신디케이션 비인식 애플리케이션 모두에 이용가능하게 하도록 구성되는 피드 동기화 엔진; 및

   피드 리스트(feed list) 및 피드 데이터를 저장하도록 구성되는 피드 저장부

   를 포함하는 시스템.
2. 제1항에 있어서,

   상기 피드 동기화 엔진은 상이한 포맷의 콘텐트를 공통 포맷으로 변환하도록 구성되는 시스템.
3. 제1항에 있어서,

   상기 피드 동기화 엔진은 복수의 상이한 유형의 스케쥴들을 지원하도록 구성되며, 상기 스케쥴들 중 적어도 하나는 갱신 사이의 기간을 규정하는 최소 갱신 시 간을 규정하는 최소 스케쥴을 포함하는 시스템.
4. 제1항에 있어서,

   상기 피드 동기화 엔진은 피드 데이터를 다운로드하고, 이전에 다운로드된 피드 데이터를 갱신하도록 구성되는 시스템.
5. 제1항에 있어서,

   상기 피드 동기화 엔진은 인클로저를 다운로드하고, 이러한 인클로저를 파일 시스템에 제공하며, 상기 인클로저가 신디케이션 비인식 애플리케이션에 의해 액세스가능한 시스템.
6. 제5항에 있어서,

   상기 플랫폼은 사용자의 프로필에 인클로저를 기입하도록 구성되는 시스템.
7. 제6항에 있어서,

   상기 플랫폼은 인클로저와 그와 연관된 피드 아이템 사이의 링크를 유지하도록 구성되는 시스템.
8. 제1항에 있어서,

   상기 피드 저장부는 파일 시스템의 일부로서 구현되는 시스템.
9. 제8항에 있어서,

   상기 피드 리스트는 서브디렉토리를 포함할 수 있는 디렉토리로서 표현되는 시스템.
10. 제8항에 있어서,

    상기 피드 리스트 및 피드 데이터는 구조화된 저장 기술을 사용하여 상기 파일 시스템에서 관리되는 시스템.
11. 제1항에 있어서,

    상기 피드 동기화 엔진은, 사용자의 애플리케이션과 게시 위치 사이의 통신 프로토콜을 무시하는 방식으로 사용자가 콘텐트를 게시할 수 있도록 구성되는 시스템.
12. 제1항에 있어서,

    상기 신디케이션 플랫폼은 피드 동기화를 행하도록 구성되는 시스템.
13. 제1항에 있어서,

    상기 콘텐트 신디케이션 플랫폼은 RSS 플랫폼을 포함하는 시스템.
14. 구독을 위한 루트 폴더로서 기능하며, 피드와 관련되는 하나 이상의 메소드(method)를 갖는 제1 인터페이스;

    피드를 위한 폴더로서 기능하며, 피드 속성 및 서브폴더 속성, 및 폴더와 관련되는 하나 이상의 메소드를 포함하는 제2 인터페이스;

    개개의 피드와 연관되는 속성 및 개개의 피드와 관련되는 하나 이상의 메소드를 포함하는 제3 인터페이스;

    개개의 아이템과 연관되는 속성 및 개개의 아이템과 관련되는 적어도 하나의 메소드를 포함하는 제4 인터페이스; 및

    개개의 인클로저와 연관되는 속성, 및 개개의 인클로저와 연관되는 하나 이상의 메소드를 포함하며, 상기 메소드 중 적어도 하나는 인클로저가 애플리케이션에 의해 다운로드되게 하는 제5 인터페이스

    를 포함하는 애플리케이션 프로그램 인터페이스의 세트를 구현하는 하나 이상의 컴퓨터 판독가능 매체를 포함하는 시스템.
15. 제14항에 있어서,

    상기 제1 인터페이스는 피드 구독을 요청하지 않으면서 피드를 다운로드하기 위한 메소드를 포함하는 시스템.
16. 제14항에 있어서,

    상기 제1 인터페이스는 애플리케이션이 시스템 피드 리스트와 관련된 통지에 대해 등록할 수 있게 하는 통지 이벤트를 포함하는 시스템.
17. 제14항에 있어서,

    상기 제2 인터페이스는 데이터가 연관된 폴더에 기입된 마지막 시간을 나타내는 속성을 포함하는 시스템.
18. 제14항에 있어서,

    상기 제3 인터페이스는 특정 피드와 연관된 아이템들의 콜렉션인 아이템 속성, 및 개개의 인클로저가 기입되는 디렉토리를 제공하는 로컬 인클로저 경로 속성을 포함하는 시스템.
19. 제14항에 있어서,

    상기 제3 인터페이스는 피드의 XML을 호출자에게 복귀시키는 메소드를 포함하는 시스템.
20. 제14항에 있어서,

    상기 제4 인터페이스는 연관된 피드를 포인팅하는 부모(parent) 속성, 및 아이템의 인클로저와 연관된 인클로저 속성을 포함하는 시스템.

Images