Caching .txt files

[WilsonOfCanada]

Hellos,

I was wondering if I can use javascript caching system to store .txt
files on the client side (as temp file). I know you can store .img
files. I want to use them later so it would not require to transfer
files from the server again. The txt files are just list of countries
so there is nothing about security, but they are just very long.

I am using Python with Django and Apache.

thanks

 

[Martin Honnen]

I was wondering if I can use javascript caching system to store .txt
files on the client side (as temp file). I know you can store .img
files. I want to use them later so it would not require to transfer
files from the server again. The txt files are just list of countries
so there is nothing about security, but they are just very long.

javascript caching system? What exactly is that? If you want the browser
to load a resource then you can use an iframe
<iframe with="0" height="0" src="foo.txt"></iframe>
no need to use script. If you think you need to do it with script then
use XMLHttpRequest to make a GET request.

 

[Jorge]

Hellos,

I was wondering if I can use javascript caching system to store .txt
files on the client side (as temp file).

If you mean as a file in the client computer's file system, no, it's not
possible, at least not in a way that JS code can access it later, with ease.

I know you can store .img
files. I want to use them later so it would not require to transfer
files from the server again.

Later means when navigating to another page in the same domain ?
Later means when reopening the browser after a previous session ?

The txt files are just list of countries
so there is nothing about security, but they are just very long.

Very long means... tens of kB ? hundreds of kB ? MB ? GB ?

I am using Python with Django and Apache.

Are you setting properly the suitable HTTP cache headers ?

 

[Thomas 'PointedEars' Lahn]

I was wondering if I can use javascript caching system to store .txt
files on the client side (as temp file). I know you can store .img
files. I want to use them later so it would not require to transfer
files from the server again.

You are confused. Probably you mean image files, as downloaded before/while
rendering image resources that might be referred to by the (X)HTML `img'
element.

It does not really matter, though. Caching as you describe it is a feature
provided by the runtime environment, here the HTTP client; not by the
programming language.

If you are referring to Image objects, as in

var img = new Image();
img.src = ...;

then this merely triggers the caching feature built-in the HTTP client
because it issues an HTTP request (or a local equivalent).

So you do not need to do anything for a resource to be cached; well, you do
need a properly configured browser, and *no* HTTP headers in the response
that allow the response to be *not* cached.

And you could store text data in a cookie or a Storage object; at least the
former can be triggered with (document.cookie = ...) and without JavaScript
(Set-Cookie/Set-Cookie2 headers); but those browser-dependent (in
MSHTML-based browsers cookies for a site may not exceed 4 KiB; see a recent
discussion, Storage is only provided by newer browsers).


PointedEars

 

[matt prokes]

Yes this can be done through dojo storage http://www.dojotoolkit.org/node/115
as long as the txt file contents is written out as a javascript
string. You may need to use a server side language, pipes, or some web
service to achieve this.

var x = "txt file contents";

, you should be able to then use dojo storage, and check for the
existence of the object on reload. If it is not there, run the
application to cache it again, otherwise display the cached data.

 

[Thomas 'PointedEars' Lahn]

Yes this can be done through dojo storage http://www.dojotoolkit.org/node/115

which requires Flash. Nice try.


PointedEars

 

[matt prokes]

which requires Flash.  Nice try.

PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
  -- Richard Cornford, cljs, <[email protected]>

Uhhhh, dojo storage doesn't NEED to use flash, it only does if it
needs to store around 500k of data, otherwise it uses cookies to store
this data. Regardless, if you want a flash-less solution, you could
always use cookies.

 

[Thomas 'PointedEars' Lahn]

Yes this can be done through dojo storagehttp://www.dojotoolkit.org/node/115

which requires Flash. Nice try.
[...]

Uhhhh, dojo storage doesn't NEED to use flash, it only does if it
needs to store around 500k of data, otherwise it uses cookies to store
this data. Regardless, if you want a flash-less solution, you could
always use cookies.

| Requires
|
| * dojo.lang
| * dojo.flash
| * dojo.event
|
| [...]
| Help! Dojo.Storage Isn't Working!
|
| Some possibilities:
|
| * You must have the following SWF files in the same directory
| as your dojo.js file: flash6_gateway.swf, storage_dialog.swf,
| Storage_version6.swf, Storage_version8.swf
| [...]
| * You are on an unsupported browser. The following are supported:
| IE 6+, Firefox, Safari.
| * You have a really old version of Flash, or no Flash, and don't
| have permission on your computer to upgrade software (perhaps
| you aren't the administrator account and don't have permission
| to install Flash?)
| * You're being served from an https domain, where there is a
| known bug right now that needs to be fixed (I can't fix it
| because I don't have an SSL/HTTPS environment setup; any
| volunteers?)

ISTM that yes, it does not only require Flash, but also a very particular
runtime environment. Especially, it would probably require the
*Macromedia/Adobe* Flash Player plugin (it doesn't say that but it can be
assumed) which provides the capability for Flash movies to store more than
the average amount of cookie data. And ISTM that this plugin needs to be
configured so that Flash is allowed sufficient storage space on the system
partition (which is not mentioned at all in the requirements).

And about the HTTPS environment: What kind of complete lusers are we dealing
with here? Do you want to trust people managing your valuable data that
cannot even accomplish that basic setup (my, you don't even need a properly
signed certificate for a test!). I for one certainly would not.


PointedEars

 

[matt prokes]

Regardless of your seemingly self consumed nature I still stand by
what I said.

Regardless, if you want a flash-less solution, you could
always use cookies.

Bash dojo storage all you want, I didn't write it.

~matt prokes

matt prokes wrote:
Yes this can be done through dojo storagehttp://www.dojotoolkit.org/node/115
which requires Flash.  Nice try.
[...]

Uhhhh, dojo storage doesn't NEED to use flash, it only does if it
needs to store around 500k of data, otherwise it uses cookies to store
this data. Regardless, if you want a flash-less solution, you could
always use cookies.

| Requires
|
|     * dojo.lang
|     * dojo.flash
|     * dojo.event
|
| [...]
| Help! Dojo.Storage Isn't Working!
|
| Some possibilities:
|
|     * You must have the following SWF files in the same directory
|       as your dojo.js file: flash6_gateway.swf, storage_dialog.swf,
|       Storage_version6.swf, Storage_version8.swf
| [...]
|     * You are on an unsupported browser. The following are supported:
|       IE 6+, Firefox, Safari.
|     * You have a really old version of Flash, or no Flash, and don't
|       have permission on your computer to upgrade software (perhaps
|       you aren't the administrator account and don't have permission
|       to install Flash?)
|     * You're being served from an https domain, where there is a
|       known bug right now that needs to be fixed (I can't fix it
|       because I don't have an SSL/HTTPS environment setup; any
|       volunteers?)

ISTM that yes, it does not only require Flash, but also a very particular
runtime environment.  Especially, it would probably require the
*Macromedia/Adobe* Flash Player plugin (it doesn't say that but it can be
assumed) which provides the capability for Flash movies to store more than
the average amount of cookie data.  And ISTM that this plugin needs to be
configured so that Flash is allowed sufficient storage space on the system
partition (which is not mentioned at all in the requirements).

And about the HTTPS environment: What kind of complete lusers are we dealing
with here?  Do you want to trust people managing your valuable data that
cannot even accomplish that basic setup (my, you don't even need a properly
signed certificate for a test!).  I for one certainly would not.

PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

 

[matt prokes]

Regardless of your seemingly self consumed nature I still stand by
what I said.

Regardless, if you want a flash-less solution, you could
always use cookies.

Bash dojo storage all you want, I didn't write it.

~matt prokes

On Jul 23, 8:54 am, Thomas 'PointedEars' Lahn <[email protected]>
wrote:
matt prokes wrote:
Yes this can be done through dojo storagehttp://www.dojotoolkit.org/node/115
which requires Flash.  Nice try.
[...]

Learn to quote.  <http://jibbering.com/faq/#posting>

| Requires
|
|     * dojo.lang
|     * dojo.flash
|     * dojo.event
|
| [...]
| Help! Dojo.Storage Isn't Working!
|
| Some possibilities:
|
|     * You must have the following SWF files in the same directory
|       as your dojo.js file: flash6_gateway.swf, storage_dialog.swf,
|       Storage_version6.swf, Storage_version8.swf
| [...]
|     * You are on an unsupported browser. The following are supported:
|       IE 6+, Firefox, Safari.
|     * You have a really old version of Flash, or no Flash, and don't
|       have permission on your computer to upgrade software (perhaps
|       you aren't the administrator account and don't have permission
|       to install Flash?)
|     * You're being served from an https domain, where there is a
|       known bug right now that needs to be fixed (I can't fix it
|       because I don't have an SSL/HTTPS environment setup; any
|       volunteers?)

ISTM that yes, it does not only require Flash, but also a very particular
runtime environment.  Especially, it would probably require the
*Macromedia/Adobe* Flash Player plugin (it doesn't say that but it can be
assumed) which provides the capability for Flash movies to store more than
the average amount of cookie data.  And ISTM that this plugin needs to be
configured so that Flash is allowed sufficient storage space on the system
partition (which is not mentioned at all in the requirements).

And about the HTTPS environment: What kind of complete lusers are we dealing
with here?  Do you want to trust people managing your valuable data that
cannot even accomplish that basic setup (my, you don't even need a properly
signed certificate for a test!).  I for one certainly would not.

PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

Also, a simple google search reveals alternatives.
http://pablotron.org/?cid=1557

 

[David Mark]

matt prokes wrote:
Yes this can be done through dojo storagehttp://www.dojotoolkit.org/node/115
which requires Flash.  Nice try.
[...]

Uhhhh, dojo storage doesn't NEED to use flash, it only does if it
needs to store around 500k of data, otherwise it uses cookies to store
this data. Regardless, if you want a flash-less solution, you could
always use cookies.

| Requires
|
|     * dojo.lang
|     * dojo.flash
|     * dojo.event

This must be old. None of these names are current. Neither is
dojo.storage. Storage is part of the DojoX extensions.

|
| [...]
| Help! Dojo.Storage Isn't Working!
|
| Some possibilities:
|
|     * You must have the following SWF files in the same directory
|       as your dojo.js file: flash6_gateway.swf, storage_dialog.swf,
|       Storage_version6.swf, Storage_version8.swf
| [...]
|     * You are on an unsupported browser. The following are supported:
|       IE 6+, Firefox, Safari.
|     * You have a really old version of Flash, or no Flash, and don't
|       have permission on your computer to upgrade software (perhaps
|       you aren't the administrator account and don't have permission
|       to install Flash?)
|     * You're being served from an https domain, where there is a
|       known bug right now that needs to be fixed (I can't fix it
|       because I don't have an SSL/HTTPS environment setup; any
|       volunteers?)

ISTM that yes, it does not only require Flash, but also a very particular

The documentation could just be wrong. Not sure as I've only glanced
at that module. Clearly minor bits of data can be stored in cookies
or HTML5 storage in almost any agent, regardless of the status of
Flash (or https, which I assume causes problems for the part of the
code dealing with Flash and/or the supplied Flash movies.) I'll deal
with the Flash stuff when I get there.

[snip]

 

[matt prokes]

again, there are alternatives to dojo storage

A simple google search reveals alternatives.
http://pablotron.org/?cid=1557

 

[David Mark]

again, there are alternatives to dojo storage

A simple google search reveals alternatives.http://pablotron.org/?cid=1557

I don't think so. From the docs:

"The most notable omission here is IE6; it should work, but I don't
have IE6 handy at the moment (MultipleIEs is temporarily busted)."

Some samples:

// test for gears

return (window.google && window.google.gears) ? true : false;

// make sure we're dealing with IE

// (src: http://javariet.dk/shared/browser_dom.htm)

return window.ActiveXObject ? true : false;

And it uses that miserable SWFObject (the jQuery of Flash scripts.)

Forget it.

 

[matt prokes]

FROM THE SITE

- Standalone: Does not need any additional browser plugins or
JavaScript libraries to work on the vast majority of current browsers.
- Backwards Compatible: Can fall back to flash -----OR----- cookies if
no client-side storage solution for the given browser is available.


PersistJS addresses all of the issues above. It currently supports
persistent client-side storage through the following backends:

* flash: Flash 8 persistent storage.
* gears: Google Gears-based persistent storage.
* localstorage: HTML5 draft storage.
* whatwg_db: HTML5 draft database storage.
* globalstorage: HTML5 draft storage (old spec).
* ie: Internet Explorer userdata behaviors.
* cookie: Cookie-based persistent storage.

Each backend exploses the exact same interface, which means you don't
have to know or care which backend is being used.


IN OTHER WORDS
He provides a consistent duct-typed interface for ALL storage
mechanisms, with the realization that one size doesn't fit all.
Simply:

// create a new client-side persistent data store
var store = new Persist.Store('My Data Store');

// pretend data
var data = "pretend this is really long data that won't fit in a
cookie";

// save data in store
store.set('saved_data', data);



Thus


You don't want to use flash?
Persist.remove('flash');

Pretty drop dead simple, oh and it works in ie6 SINCE IE6 HAS
COOKIES..
I am tired.. Going to bed.

 

[David Mark]

FROM THE SITE

I think the site speaks for itself (without resorting to SHOUTING.)

- Standalone: Does not need any additional browser plugins or
So?

JavaScript libraries to work on the vast majority of current browsers.

Of course, IE6 is a gray area. I suppose if the jQuery proponents are
to be believed, it is almost impossible to write scripts for that
obscure agent and it would be better to just ignore users who insist
on using it. Don't know how anyone managed to get by from
1999-2006.

- Backwards Compatible: Can fall back to flash -----OR----- cookies if
no client-side storage solution for the given browser is available.

That's an odd use of that term.

PersistJS addresses all of the issues above. It currently supports
persistent client-side storage through the following backends:

Are you just quoting from the site?

    * flash: Flash 8 persistent storage.
    * gears: Google Gears-based persistent storage.
    * localstorage: HTML5 draft storage.
    * whatwg_db: HTML5 draft database storage.
    * globalstorage: HTML5 draft storage (old spec).
    * ie: Internet Explorer userdata behaviors.
    * cookie: Cookie-based persistent storage.
So?


Each backend exploses the exact same interface, which means you don't
have to know or care which backend is being used.

Odd use of that term too.

IN OTHER WORDS

Stop shouting.

He provides a consistent duct-typed interface for ALL storage
mechanisms, with the realization that one size doesn't fit all.

I see. He's the Red Green of JS.

Simply:

// create a new client-side persistent data store
var store = new Persist.Store('My Data Store');

What could be simpler?

// pretend data
var data = "pretend this is really long data that won't fit in a
cookie";
Okay.


// save data in store
store.set('saved_data', data);

And just *look* at the difference!

Thus

You don't want to use flash?
Persist.remove('flash');
Handy!


Pretty drop dead simple, oh and it works in ie6 SINCE IE6 HAS
COOKIES..

Yes, the phrase "drop dead" came to mind. The author seems unsure
about IE6 though.

I am tired.. Going to bed.

Night.

 

[matt prokes]

Well there you have it . Hope it helps.
~matt

 

[John G Harris]

He provides a consistent duct-typed interface for ALL storage
mechanisms, with the realization that one size doesn't fit all.

<snip>

I think you mean duck-typed. See "duck typing" in wikipedia.

John