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

Re: New filesystem/directory API proposal

From: イアンフェッティ <ifette@google.com>
Date: Thu, 4 Feb 2010 12:28:08 -0800
Message-ID: <bbeaa26f1002041228q3c4d1c76u3bb63f7d54df5c08@mail.gmail.com>
To: Jeremy Orlow <jorlow@chromium.org>
Cc: Arve Bersvendsen <arveb@opera.com>, Eric Uhrhane <ericu@google.com>, Anselm R Garbe <garbeam@gmail.com>, public-device-apis@w3.org
I'm not sure I understand the problem. Let's say your use case is Midnight /
Norton / Total Commander (have no idea what any of these products are, I
assume AV?). Why do they need to write filenames that don't conform to the
restrictions posited above?

-Ian

2010/2/4 Jeremy Orlow <jorlow@chromium.org>

> On Thu, Feb 4, 2010 at 11:46 AM, Arve Bersvendsen <arveb@opera.com> wrote:
>
>> On Thu, 04 Feb 2010 19:24:13 +0100, Eric Uhrhane <ericu@google.com>
>> wrote:
>>
>>  I think you leave the realm of "corner cases" when you're talking
>>> about the behavior of the majority of systems on which the code can be
>>> expected to run.  And by adding these [fairly minor, IMO] restrictions
>>> on filenames, your app developers don't have to write
>>> platform-specific code at all--they just write to the web platform.
>>>
>>
>> The downside to adding restrictions is that you also restrict where and
>> how the Filesystem/directory API can or can't be used.  If your use-case is
>> roughly allowing Flickr to crawl your photo directory and upload at will,
>> you're not going to get into trouble.  If, on the other hand, your use-case
>> is more complex (imagine something like Midnight/Norton/Total commander as a
>> locally installed widget), this least-common-denominator approach is going
>> to cause problems.
>
>
> Those are 2 pretty distinct use cases.  Maybe both need to be supported by
> the API?
>
Received on Thursday, 4 February 2010 20:28:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:17 UTC