Re: 'Pure' client-side javscript database?
Available news archives: comp.lang.tcl - comp.lang.python - comp.security.firewalls - sci.crypt - comp.lang.php - comp.lang.javascript
Google
 
Web news.hping.org


comp.lang.javascript archive

Re: 'Pure' client-side javscript database?

From: Jim Davis <newsmonkey@vboston.com>
Date: Mon Aug 29 2005 - 06:57:09 CEST

"Richard Cornford" <Richard@litotes.demon.co.uk> wrote in message
news:dets1m$njb$1$8300dec7@news.demon.co.uk...
> Kevin wrote:
>> Richard Cornford wrote:
>>> A client-side database? Now there is a spectacularly bad idea. The
>>> last thing you want to do is have the client download an entire
>>> database just so it can extract a tiny part of it. Server-side is
>>> where the database belongs, and where the task of extracting data
>>> from it should happen.
>>
>> Well, he didn't say anything about downloading an entire database.
> <snip>

Well - it doesn't really matter... if it makes sense to download your entire
database, do it. "Database" says nothing about size: the databases for many
applications are only a few kb, if that.

> Have you considered the implications of "implemented a database with a
> subset of SQL in pure client-side javascript"? Particularly the words
> "in pure client-side javascript". If the only active technology used is
> client-side javascript then the data has to go to the client.

That's the way I read it too... data and the code to manipulate it on the
client.

I see absolutely no benefit to be had in doing client-side SQL against a
server-side database... although I could be convinced I suppose it'll be a
damn hard sell.

It seems to me, unless I'm missing something, that the argument is rather
silly. Whatever you call it storing data on the client has been shown to be
incredibly useful in a tremendous number of applications. However most
applications just call it caching - you can call it a "database" if you like
but data sent the client but not displayed... well, damn - that's a cache.

I see no reason that a client-side cache couldn't be managed with
client-side SQL if it made sense to do so.

>> For that matter, client-only applications can simply use
>> DHTML as a display device, and never connect to a server.
>
> Is a browser still a client if there is no server? Without a server
> don't you have a stand alone application running in a browser?

Well, yes. Perhaps not a "client-server" application but you still have a
JavaScript application in a browser container of some kind which might just
need a client-side database to manage... something or other.

There are many good uses for a browser-client obtaining application code
from a server and then running that code "off-line". I've built a few
complex HTA's that do just that: the application is delivered via HTTP (and
thus always up to date) but actually runs soley on the client. Granted most
requested further information from the server... but some don't.

For example I've got a simple HTA which loops through my Windows Media
Player library and creates relatively-linked playlists for all the albums it
finds in there. (The playlists make things easier for my older PocketPC.)
The application runs off-line, does not connect to an HTTP server at all but
is still a JavaScript application.

Of course it doesn't need a database... but dammit, something might! ;^)

Jim Davis
Received on Tue Oct 18 03:14:04 2005