구글 데스크탑을 사용해서 서버 파일검색 구현

 
일단 스샷부터 찍어놓고.. 이런 식으로 블로그 페이지에 포함시켰다.

기본적으로 구글 데스크탑 Search API를 사용한 파일 검색에는 몇 가지 방법이 있다. 케냘이 시도한 것은 세 가지인데, 뭐 더 있을지도 모르겠지만 더 이상 시도하기도 귀찮고 이 이상의 기능이 필요한 것도 아니어서- 일단 개략적인 부분을 알고 싶은 사람은 다음 링크를 살펴보자(영문이다) : Google Desktop SDK > Search API > Query API Developer Guide 케냘이 시도한 세 가지는 어떤 것이냐면 :

1. 리디렉션 서비스 구현
   구글 데스크탑의 url을 살펴본 적이 있는 사람은 알겠지만, 구글 데스크탑 서비스는 로컬에서만 작동하는 일종의 웹 서비스를 구동한다. 해당 웹 서비스의 URL은 http://127.0.0.1:4664/search? 과 같은 형태를 하는데, 단순히 127.0.0.1 주소의 4664번 포트에 대한 리디렉션 서비스를 만들어서 외부의 웹 호출을 이 주소로 돌려놓기만 하면 될 줄 알았다만... 세상 일이 그렇게 쉬우면 안 되지요. 실제 파일과 연결되는 URL을 필터링해서 값을 변경(127.0.0.1:4664 주소를 웹 서버의 주소로 맵핑하는 등)하는 작업도 필요했고, 구글 데스크탑에서 나온 검색 결과를 클릭할 때도 로컬 OS 환경과 상호작용한다는 것을 이때는 몰랐다. 예를 들면, 이런 형태로 구현하고 나서 나온 URL을 클릭하면 클라이언트에서 서버의 파일을 가져오는게 아니라, 서버(그냥 서버의 사용자 세션)에서 파일이 열린다. 그렇다면 구글 데스크탑에 들어있는, 로컬 OS와 연동하는 js 스크립트까지 몽땅 필터링을 하든가 수정하든가 해야 한단 이야기인데. 이런 js 스크립트는 GoogleDesktop.exe 파일 내에 박혀 있는 형태라서 변경은 불가. 필터링을 더 하자니 이건 도대체 사람이 할 일이 아니었다... 그래서 일단 여기까지 해보고 접음.
   
   * 이런 형태의 프로그램으로 Google Desktop Proxy가 공개되어 있으나, 이 프로그램은 구글 데스크탑의 최신 버전과 호환되지 않았다. 그래서 케냘은 이걸 직접 구현하려 했다 ;;
    
2. Google Search API를 호출하는 닷넷 어셈블리 사용
   구글 데스크탑을 설치하면 구글 데스크탑 관련 컴포넌트 몇 개가 시스템에 설치된다. Visual Studio 사용자는 참조 추가 메뉴에서 컴포넌트의 목록을 살펴볼 수 있다.
   
   
   
   asp.net 환경에서 사용할 수 있도록 Search API(GDS Query API 1.0을 사용했다)를 적당히 포장해서 사용하면 되리라고 생각했으나, 이마저도 만만치 않아서. 로컬 머신에서 구동할 때(그러니까, 개발 서버)는 아무 이상이 없었지만, 원격에서 호출하니 Class Factory를 못 찾는다는 에러가 발생. 벼라별 짓을 다 해보았지만 결국 해결을 못 했다. 아직도 이 원인은 잘 모르겠음. 닷넷의 CAS 관련 문제는 아닌 것 같고, 구글 데스크탑 API 라이브러리가 뭔가 희한하게 컴파일되어 있는 것 같다. 단순히 Unmanaged 바이너리를 호출한다고 해도 Unsafe 관련이나 CAS 문제가 생긴다면 모를까 Class Factory를 못 찾는다는건 그냥 컴포넌트가 등록 안 되었다는 얘기인데... 과거 C#/ASP.NET MVP가 이런 문제도 해결 못해서야 어디 쪽팔려서... ( ;ㅁ;)
    
3. HTTP/XML로 구글 데스크탑의 검색 결과 가져오기
   알고 보니 이게 구글에서도 추천하는 방법이더라. 결국 모든 답은 제작사의 Guideline에 달려 있는 것이다. 여튼 이건 짧게 설명한다면... 아까의 구글 데스크탑 검색 URL(http://127.0.0.1:4664 같은...)의 맨 마지막 부분에 &format=xml를 추가해주면 검색 결과가 xml로 변환되어 들어온다. 대충 이런 형태다 :
   
   

   <?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
   <!--
   Content-type: fix-mhtml
   -->
   <results count="2520">
   <result>
     <category>file</category>
     <doc_id>232866</doc_id>
     <event_id>268063</event_id>
     <title><b>test</b>[1].wpost</title>
     <url>D:\My Documents\My Weblog Posts\Recent Posts\test[1].wpost</url>
     <flags>0</flags>
     <time>128341215358620000</time>
     <icon>/file.gif</icon>
     <cache_url>http://127.0.0.1:4664/redir?url=http%3A%2F%2F127%2E0%2E0%2E1%3A4664%2Fcache%3Fevent%5Fid%3D268063%26schema%5Fid%3D8%26q%3Dtest%26s%3DsZ%5FyCD6HYoBm1XKpmIM6ZFK3QB0&src=1&schema=8&s=lvQD5Q3ByYz6NrndhQRluxsS0ck</cache_url>
     </result>
   <result>
     <category>email</category>
     <doc_id>232851</doc_id>
     <event_id>267974</event_id>
     <title>No investment needed.</title>
     <url>googlemail://No investment needed.</url>
     <flags>2</flags>
     <from>claybourne maurice</from>
     <folder>Trash</folder>
     <time>128340681140000000</time>
     <snippet>So either you can attach the drug to the outer surface, or fill it up like a <b>test</b> tube, says Dai. Furthermore, multiple functional molecules can be attached to the surface: Say, a molecule that</snippet>
     <icon>/read.gif</icon>
     <cache_url>http://127.0.0.1:4664/redir?url=http%3A%2F%2F127%2E0%2E0%2E1%3A4664%2Fcache%3Fevent%5Fid%3D267974%26schema%5Fid%3D1%26q%3Dtest%26s%3D0n5eQMxQELkOe%5FuDEUCbnPQOkWQ&src=1&schema=1&s=fuYaa64y756wBH4-FjJSCMgDx3g</cache_url>
     <message_id>1939687912 2746509175 000701c7f53a$079da0d8$8d4fb0a0@xmplg</message_id>
   </result>
   ...
   </results>

   이렇게 얻은 XML 문서를 잘 주물러서, 포스트 맨 위에 나타난 것 같은 페이지 형태로 가공해서 내놓으면 끝. 물론 url을 가공해서 링크를 만들 때에도 몇 가지 고려해야 할 점이 있기는 한데, 그건 뭐 여기까지 개발할 수 있는 사람이라면 알아서 해결할 수 있을 줄로 알고(사실은 소스코드 열어보기가 귀찮아;;) 그냥 넘어가도록 하겠다.

이렇게까지 해서 만들어 놨는데 사람들이 안 쓰면 낭패 ... ( 'ㅅ`)

구글 데스크탑을 주물럭거리면서 느끼는 거지만, 구글에서 나오는 어플리케이션의 바이너리 배포 정책 담당자는 정말 기술 지향적인 사람인 듯. GDS만 이런건지는 모르겠는데.. 대체 어디까지 최적화를 해야 속이 시원한 건지 관련 코드 살펴보다가 reformat을 하고 나서 코드를 살펴봐야 하나 수십번은 고민했다. 물론 이제는 내가 코딩을 잘 안한다는 사실의 반증이기도 하겠지만.

아아 문득 코딩을 계속하고 싶지만 할 일이 많다.
언제쯤에야 나는 마음편히 코딩을 즐기며 여생을 보낼 수 있을 것인가...