본 글의 원문은 Why no FileSystem API in Firefox?이며 Jonas Sicking이 쓴 글입니다.

많은 분들이 왜 Firefox는 FileSystem API를 지원하지 않는지 의문을 가지고 있습니다. 대부분 Google이 Chrome 구현하고 W3C에서 표준화 제안을 하고 있는 FileSystem 와 FileWriter에 대한 질문입니다.

결론적으로 이 문제는 다소 복잡하고 질문하는 사람이 위의 두 가지 사양 중에서 실제로 어떤 기능을 사용할 것인가에 크게 의존하고 있습니다. 이들 표준은 내용도 많고 기능도 풍부합니다. 따라서 각자가 완전히 다른 것을 바라보고 있습니다. 이 글에서는 이 질문에 대한 제 개인적인 답변과 우리가 위의 두 사양을 구현하지 않은 이유에 대해 설명하고자 합니다. 하지만, 이 글은 개인의 의견이며 이 주제에 대해 많은 논의가 이루어질 것을 의도하고 있습니다.

리소스를 로컬에 저장하기

가장 일반적인 요구는 단순히 자원을 로컬로 저장하고 네트워크에 연결되어 있지 않아도 사용할 수 있게 하고 싶다는 것입니다. 이것은 리소스에 즉시 접근할 필요가 있거나 사용자가 오프라인으로 리소스에 접근할 수 있도록 하려는 경우에 유용합니다. 게임 등 대부분이 이런 요구가 있는 응용 프로그램입니다. 예를 들어, 적군 비행선과 연관된 이미지와 두 개의 연관된 오디오를 가지고, 적이 화면을 돌아다니며 공격 올 때 그것이 사용 될 수 있습니다. 오늘날 사람들은 일반적으로 이미지와 음성 파일을 파일 시스템에 미리 저장하여 이 문제를 해결하고 있습니다.

이러한 몇 가지 데이터를 나눠 저장하는 것은 개인적으로 나쁜 방법은 아니라고 생각합니다. 특히 구조화된 데이터와 파일 데이터를 모두 저장할 수 있는 해결책이 있을 것 같습니다. IndexedDB는 파일 데이터를 일반 데이터처럼 처리할 수 있습니다. 문자열, 숫자 값 또는 JavaScript 개체를 저장하는 것과 마찬가지로 File 이나 Blob 을 IndexedDB에 저장할 수 있습니다. 이것은 IndexedDB 사양에 지정되어 있으며, 현재 Firefox 및 IE에서 모두 IndexedDB의 사양에 따라 구현되어 있습니다. 이것을 사용하여 필요한 모든 정보를 한 곳에 저장할 수 있으며, 한번의 쿼리로 필요한 모든 데이터를 반환할 수 있습니다.

코드 예제를 살펴 봅시다. 웹 기반의 메일 클라이언트를 구축하는 것이라면, 다음과 같이 할 수 있습니다.

{
  subject: "Hi there",
  body: "Hi Sven,\nHow are you doing...",
  attachments: [blob1, blob2, blob3]
}

여기에 또 다른 장점은 리소스 파일에 이름을 붙일 필요가 없는 것입니다. File 개체 또는 Blob 객체를 저장하면, 이름은 필요하지 않습니다.

Firefox의 IndexedDB 구현 (IE도 마찬가지)는 파일을 실제 DB 외부에 투명하게 저장됩니다. 이것은 IndexedDB에 파일을 저장하는 것이 파일 시스템에 저장하는 것보다 성능이 좋다는 것을 의미합니다. 데이터베이스에 파일을 담아 다른 작업이 늦어지는 것은 없습니다. DB에 저장하고 그 파일을 읽는 것은 OS와 같은 구현임을 의미하고, 파일 시스템과 같은 속도로 읽을 수 있습니다.

Firefox의 IndexedDB 구현은 같은 Blob 여러 파일을 IndexedDB 데이터베이스에 저장하는 경우도 파일의 복사본을 하나 만들 뿐이므로 충분히 스마트합니다. 같은 Blob에 추가 참조를 써도 내부 참조 카운터를 추가하면 됩니다. 이것은 웹 페이지에서도 사용 가능하고, 쓰기가 빠르고 리소스 소비가 적다는 것 입니다. 아직 IE에서 구현은 어떤지 모르겠습니다.

사진과 음악 폴더에 대한 접근

두 번째로 파일 시스템 API에 대한 사용 사례는 바로 사용자의 사진 폴더나 음악 폴더에 접근할 수 있는지 하는 것입니다. 이것은 W3C에 제안된 FileSystem API가 실제로 제공하지 않는 기능이지만, 많은 사람들이 하고 싶어 하는 것 중 하나입니다. 이 사례를 만족 시키기 위해 DeviceStorage API 를 사용할 수 있습니다. 이 API는 “사용자 파일”에 액세스할 수 있는 완전한 파일 시스템 권한이 있습니다. 즉, 파일은 웹사이트 고유의 것이 아니라, 사용자가 관리 및 소유하고 있는 자원이며, 사진과 음악 파일을 처리할 때와 같이 사용자가 개별 애플리케이션을 통해 접근할 수 있습니다. DeviceStorage API는 기본적으로 간단한 파일 시스템 API이며, 이러한 유형의 파일에 최적화되어 있습니다.

이 API는 표준 개발 및 구현 단계에 있습니다. 최근 nightly 빌드를 테스트할 수 있지만 아직 기본적으로 활성화되어 있지 않습니다. 이 기능상 가장 큰 문제는 보안입니다. 웹 사이트에서 직접 여러분의 이미지를로드하거나 변경하거나 하고 싶지 않을 것입니다. 이 API는 과거 사용자의 사진을 삭제하는 기능이 있는 API이므로 GeoLocation API에서 처럼 확인 대화 상자를 두어야 합니다. 그리고 앞으로 개선해야 하는 사안으로 뭔가 더 필요한 것이 있는지 살펴보아야 합니다.

낮은 수준의 파일 작업

일반적이지 않은 요청은 낮은 수준의 파일 작업인 생성하고, 읽고, 업데이트하고 삭제하는(CRUD; create, read, update, delete의 머리 글자를 딴 것) 작업입니다. 예를 들어, 10MB의 파일의 중간에 10 byte 쓰기를 원한다면 어떻게 할까요? IndexedDB는 아직 이를 지원하지 않고 전체 파일 추가 삭제만 가능합니다. 이것은 FileWriter 사양의 초안에서 지원됩니다. 그러나 이 부분의 API는 아주 근본적인 문제를 안고 있습니다. 특히,이 사양은 파일 잠금 능력이 없기 때문에 여러 파일 작업을 동시에 할 수없어 작업을 하는 동안 다른 탭에서 파일을 변경하고 로드하는 일이 없도록 해야 합니다. 또한, fsync하는 수단도 없기 때문에 데이터베이스와 같은 ACID 유형의 응용 프로그램 FileWriter에 구현할 수 없습니다.

우리는 대신 같은 목표를 가지고 파일 잠금과 동시에 여러 작업을 수행할 기능이 있는 API를 만들었습니다. 이것은 웹 페이지가 파일 잠금 해제를 잊어버리는 상태가 발생할 위험이 없는 방식으로 이루어집니다. 이 API는 fsync 작업을 받아들이고 FileHandle의 데이터베이스가 실시하는 것도 가능합니다. 그러나 가장 중요한 것은 API FileWriter와 같이 비동기 콜백을 중첩하지 않아도 좋은 방식으로 구현되는 것입니다. 즉 개발자에게 친숙한 API라는 것입니다. FileHandle에 대한 자세한 내용은 https://wiki.mozilla.org/WebAPI/FileHandleAPI 을 읽어 보시기 바랍니다.

filesystem URL 체계

위의 FileSystem API가 커버 하지 않는 또 다른 기능이 있습니다. 이 사양은 새로운 filesystem: URL 체계를 도입합니다. URL을 filesystem: 에서 읽어 들일 때, FileSystem API를 사용하여 저장된 파일의 내용을 반환합니다. 이것은 다음 두 가지 이유로 매우 멋진 기능이라고 할 수 있습니다. 첫째, 이러한 모든 URL을 예상할 수 있는 것입니다. 파일 시스템의 파일에 한 번 저장하면 그것을 읽는 데 사용되는 URL을 항상 알고 있는 것입니다. 또한, URL은 파일을 파일 시스템에 저장 되어있는 한 웹 페이지를 다시 읽어서 계속 사용할 수 있습니다. 둘째, 상대 URL을 filesystem: 구성표에 사용할 수 있습니다. 따라서 한 파일 시스템에 저장된 리소스에서 다른 파일 시스템에 저장되거나 소스까지 모든 img 링크를 만들 수 있습니다.

Firefox는 blob:URL 체계를 지원하지 않습니다. 이것은 URL이 사용되는 어디에서 Blob 데이터를 가져올 수 있습니다. 그러나 위의 기능은 없으며 해결책을 발견하고 찾아볼 것입니다. 만약 더 나은 해결책을 찾을 수 없는 경우 Google의 사양을 구현 할 수 밖에 없을 것입니다.

맺으면서

웹 플랫폼에 추가되는 기능에 대해 말할 때는 언제나 그렇듯 사례와 능력에 대해 이야기로 출발하여 특정 솔루션에 직접 다가가는 것이 중요합니다. 많은 FileSystem API에서 해결하려고 하는 문제는 다른 방법으로 해결할 수 있습니다. 제 의견으로는 그러한 개선이 여러 번 있습니다.

이것이 우리가 FileSystem API를 우선적으로 구현하지 않는 이유입니다. 대신 IndexedDB 구현을 좋아하거나 낮은 수준의 파일 작업을 위한 API를 해결하는데 초점을 맞추고 있습니다. IndexedDB에 초점을 맞추는 것은 기본적인 파일 저장을 위한 좋은 API가 3개의 브라우저 (IE10, Firefox, Chrome)에 즉시 사용할 수 있게되는 것을 의미합니다.

관련해서 최근 우리 IndexedDB 구현 사양 준수에 대한 마지막 문제를 해결하는 곳입니다. Firefox 16에서는 벤더 접두사 없이 사양에 준거한 IndexedDB를 사용할 수있게됩니다! 항상 그렇듯이, 우리는 많은 사람들의 의견, 특히 웹 개발자의 의견에 매우 흥미가 있습니다. FileSystem API를 우선적으로 취급 해야 한다고 생각하십니까? 그 이유는 무엇인가요?