Re: 'Pure' client-side javscript database?

Jim Davis wrote:
> Richard Cornford wrote:
>> Kevin wrote:
>>> 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.

OK, the database might be trivially small. But even then "database"
implies a general concept including information describing relationships
within the database. An application specific data source will be
smaller, as it can represent relationships implicitly and avoid the
overheads of a general interface (and can be created by pre-processing,
or dynamically, from a real database).

<snip>
> I see absolutely no benefit to be had in doing client-side SQL
> against a server-side database...

No, that is potentially worse overall. Especially when you see examples
where the url, user name and password for database access are in the
client-side source code, with all of the security implications that
brings (granted the user name in question might (should) not have full
access rights to the database (so they could not just delete it) but
when the author has not thought enough to see why they should not have
exposed the url, user name and password how often will they have
considered which rights they should grant the remote user?).

There is also the question of clean degradation. Without client-side
scripting the entire system would be non-functional, in a way that
server-side database querying would not be.

> 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.

Are we talking about storing data on the client here? The standard
security model for Internet browsers does not allow explicit writing to
the local hard discs, so any notion of storage is either in the
browser's memory or it is Internet cache, both of which are somewhat
ephemeral.

(The group's stated "context of use" assumption (as stated in the FAQ);
that we are discussing a public Internet use, applies here as the OP
mentioned no other context.)

> 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.

Wouldn't the extent to which it make sense to use client-side SQL have a
strong relationship to the size of the client-side database, and so
return us to the question of the wisdom of downloading such a bulk of
information.

>>> 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
<snip>

But is the browser a client if there is no server?

> 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.
<snip>

And an HTA has access to the local file system and can interact with a
local Access database, if that is what is needed.

Richard.
Received on Tue Oct 18 03:14:53 2005