W3C home > Mailing lists > Public > public-device-apis@w3.org > January 2010

Re: New filesystem/directory API proposal

From: Eric Uhrhane <ericu@google.com>
Date: Fri, 29 Jan 2010 14:49:36 -0800
Message-ID: <44b058fe1001291449y40446bfah3dd2e275b0f12bd4@mail.gmail.com>
To: Arve Bersvendsen <arveb@opera.com>
Cc: public-device-apis@w3.org
On Fri, Jan 29, 2010 at 2:20 PM, Arve Bersvendsen <arveb@opera.com> wrote:
> On Fri, 29 Jan 2010 22:32:11 +0100, Eric Uhrhane <ericu@google.com> wrote:
>
>> I took out the zip operation for now, as I'm not sure what the use cases
>> are. Zip and unzip can be written in JavaScript [e.g.
>>  http://jszip.stuartk.co.uk/].
>> If speed will be an issue, please respond with use cases.
>
> Use cases for having zip in:
>
> 1. Widgets are zip files, and being able to traverse directly into the zip
> without explicitly decompressing it is awfully convenient.
> 2. Ditto for epub
> 3. and ODF
> 4. also OOXML
>
> I guess what I'm getting at here is that there are a lot of document types
> that applications will want to peek inside, for which having transparent zip
> support is extremely convenient. Any effort spent on our part here is going
> to save a lot of work for other developers in the future.

OK, so what you'd want would be to have an Entry that was a zip file
[or other archive type], but you could look inside it as if it were a
directory?  You're not asking for the ability to zip or unzip an
archive using a built-in command?  Let me think about how to do this
cleanly.

Thanks for the feedback; keep it coming!

     Eric
Received on Friday, 29 January 2010 22:50:26 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:41 UTC