Re: 'Pure' client-side javscript database?

"Richard Cornford" <Richard@litotes.demon.co.uk> wrote in message
news:df2ubs$pe8$1$8302bc10@news.demon.co.uk...
> Jim Davis wrote:
>> Richard Cornford wrote:

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

As others have noted while an application-specific method may be more
effective it may also be less maintainable by the developers in question:
having the (I assume) known abstraction of SQL may afford certain groups a
level of comfort when working with the data.

<snip>

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

Unless I've missed something I think we're definately talking about
client-side data storage. Doing SQL from the client to the server is (we
all agree I think) a silly idea and doing SQL from the server to client is
even more ridiculous. What's left in this arena is data on the client, SQL
on the client.

I wasn't considering any specific storage mechanism, but in memory is the
obvious choiuce when it comes to general browser-based applications.

How persistent the storage mechanism is will definately play a role in
deciding on it's use, but it's not at all blanket factor. There are many
scenarios where caching "largish" sets of data to the client can improve
interface responsiveness dramtically. This shouldn't be considered lightly
however: at the very least the additional complexity should be considered a
significant negative. (Although, of course, this is exactly what a canned
library would seek to minimize.)

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

Although I mention such use later it was in reply to a fork in the
conversation, not the original poster. In any case the FAQ does not limit
conversation to public internet use and while the original poster may not
have required this for non-public use it definately does have potential in
that arena.

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

Exactly - but that doesn't discount it.

I refuse to argue generalities. It is true (I can't agree more) that such a
system (client-side data storage and client-side SQL) is NOT practical in
the vast majority of cases. This doesn't mean that it's never useful.

As I noted the full "database" for Firstnight.org is in the range of 100kb
or so... natively it's highly relational. I can see how some people will
similar datasets and user-behavior may find something like this useful.

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

Yes - or at the very least it may be. The point is simply that the client
may download an application from a server and run it locally. The browser
is still a client of that server, but the APPLICATION may or may not be.

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

Yes... but could also download it's data from a centralized server and use
the client-side SQL mentioned against a memory resident copy.

I wasn't suggesting that HTAs were the only place that this could be done.
I was only saying that it was while building them that I did that. The same
idea (downloading an application to run on the client) can be done in pretty
much any browser (and, depending on your definition of "application" is a
very common practice).

In the end all I'm maintaining is that the very idea of client-side data and
a SQL interface to it isn't without merit in some scenarios. Nothing else.
No argument for other, more traditional options, will change that in _some
scenarios_ for _some people_ this may be useful.

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