> Hope that makes sense...

Sorry, I still don't understand.

Doesn't the openFiles() function already do what you want?
http://code.google.com/apis/gears/api_desktop.html



On Mon, Oct 27, 2008 at 12:53 AM, Khookie <[EMAIL PROTECTED]> wrote:
>
> I would like to import & export files on client-side Javascript when a
> Gears application is disconnected.
>
> Example: when it's connected, it's not hard to do through something
> like server-side PHP & HTML (i.e. setting the Content-Disposition
> header for downloads & using <INPUT TYPE="file" for uploads)... but I
> would like that capability when it's disconnected.
>
> Hope that makes sense...
>
> Cheers
>
> Chris
>
> On Oct 27, 5:42 pm, "Chris Prince" <[EMAIL PROTECTED]> wrote:
>> Can you explain a little more about what you want to achieve?
>>
>> I usually think of "access to blob contents" as building up a Blob 
>> byte-by-byte.
>>
>> But for importing text files, that shouldn't be necessary, right?
>> Something like the openFiles() API would allow importing as Blob.
>>
>> (To answer your other question: one reason direct Blob access hasn't
>> been designed is that there haven't been many concrete use cases yet.
>> It's critical to have a number of important use cases before designing
>> and building a feature!)
>>
>> On Sun, Oct 26, 2008 at 11:36 PM, Khookie <[EMAIL PROTECTED]> wrote:
>>
>> > I noticed a few people in the past have voiced concerns about wanting
>> > to read the contents of a blob.
>>
>> > I was wondering what the issues are with reading the contents of a
>> > blob on client-side JS?  I presume they're security related?
>>
>> > For my particular use case, I would really like users to be able to
>> > import text files into a local database while disconnected.  Right
>> > now, I'm using copy & paste but having access to blob contents would
>> > be so much more usable.
>>
>> > And also, will client-side file writing be available in the future as
>> > well?  Exactly like the aforementioned scenario above but exporting
>> > text files.
>>
>> > Cheers
>>
>> > Chris
>

Reply via email to