By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
425,992 Members | 934 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 425,992 IT Pros & Developers. It's quick & easy.

'Pure' client-side javscript database?

P: n/a
cjl
Hey all:

I know that it is silly in the age of Google to 'lose' something on the
internet, but I recently checked out a project that had implemented a
database with a subset of SQL in pure client-side javascript.

I forgot to bookmark it, and now I can't find it.

Anyone?

Thanks in advance,
-CJL

Aug 27 '05 #1
Share this Question
Share on Google+
18 Replies


P: n/a
cjl
Hey all:

Found it. Dang.

http://trimpath.com/project/wiki/TrimQuery

Thanks,
CJL

Aug 27 '05 #2

P: n/a
"cjl" <cj****@gmail.com> kirjoitti
viestissä:11**********************@g44g2000cwa.goo glegroups.com...
Hey all:

I know that it is silly in the age of Google to 'lose' something on the
internet, but I recently checked out a project that had implemented a
database with a subset of SQL in pure client-side javascript.

I forgot to bookmark it, and now I can't find it.

I'm glad you found it, but I MUST protest, that revealing the database
structure to end-users (clients) is asking for hacks, especially when the
site also provides the possibility to run queries. That's just like making a
sign for burglar: "Please come here and steal everything we have, we don't
lock doors or have alarms and our dog is actually just a chihuahua." That's
a warm welcome for hackers. What prevents me from running "DROP DATABASE
xyz" from javascript console?

Do pay attention to database security and user rights if and when you
implement that sort of environment. It seems to me a very high risk. Unless
this is for intranet or some sort of restricted user group?

--
SETI @ Home - Donate your cpu's idle time to science.
Further reading at <http://setiweb.ssl.berkeley.edu/>
Kimmo Laine <et****************@5P4Mgmail.com>
Aug 27 '05 #3

P: n/a
cjl wrote:
I know that it is silly in the age of Google to 'lose' something on
the internet, but I recently checked out a project that had
implemented a database with a subset of SQL in pure client-side
javascript.


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.

Richard.
Aug 27 '05 #4

P: n/a
Hi Kimmo,


I'm glad you found it, but I MUST protest, that revealing the database
structure to end-users (clients) is asking for hacks, especially when the
site also provides the possibility to run queries. That's just like making
a sign for burglar: "Please come here and steal everything we have, we
don't lock doors or have alarms and our dog is actually just a chihuahua."
That's a warm welcome for hackers. What prevents me from running "DROP
DATABASE xyz" from javascript console?


It is a client-side code, whatever you drop, you drop from your
browser/session only.
Nothing affect other users.

It is a mean to store data for the current user. I see this as a nice
companion for DHTML pages.
Do pay attention to database security and user rights if and when you
implement that sort of environment. It seems to me a very high risk.
Unless this is for intranet or some sort of restricted user group?


Elias
Aug 28 '05 #5

P: n/a
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. He
just wanted a local db interface. Absolutely nothing wrong with that.

There are lots of reasons for wanting local storage. In my own case,
we do a lot of offline processing, due to lack of connection ability in
the field.

For that matter, client-only applications can simply use DHTML as a
display device, and never connect to a server.

Cheers, Kev

Aug 28 '05 #6

P: n/a
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>

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

Richard.
Aug 29 '05 #7

P: n/a
"Richard Cornford" <Ri*****@litotes.demon.co.uk> wrote in message
news:de*******************@news.demon.co.uk...
cjl wrote:
I know that it is silly in the age of Google to 'lose' something on
the internet, but I recently checked out a project that had
implemented a database with a subset of SQL in pure client-side
javascript.


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.


Although I agree with you in general I think there are many scenarios where
this could be useful. It really depends on the data in question and the
circumstances of its use, I think.

For example I've worked for the past 10 years or so on a large public
festival here in Boston. The one-day long event features about 200 artists
appearing at 60 or so venues. The basic data set: Artist, a short
description, performance times, categories and venues is, perhaps, 75-100kb.
Here's the page from last year's event:

http://www.firstnight.org/Content/Ne...lore/Index.cfm

Now in this case the site is a non-profit and the server is slow (donated).
However the event is popular: we get several hundred thousand requests
between 10 and 12 on the morning of the event - this can start to drag
things down. The most popular way to search is to visit several slices
(certain categories, times or venues) and create a list of those things
you're interested in.

Now... downloading just the data and client-side application to display
would be larger than downloading just those pages: but when compared to two
or three requests for subsections of data (which our metrics show is
average) it would be smaller and much, much faster. The server would also
be getting a much desired break because it would be, essentially, passing
down static content which would enable much the same functionality.

Of course there's also no reason that the database has to be "whole"...
passing down predicitve data can make for a much more usuable interface.
For example a site which displays television schedules might actually
display only a two hour slice of data... but passing down four hours in the
assumption that the users will want to see "what's on next" seems a safe
bet. In this case the two hours worth of data could be passed down and page
displayed. However, in the background the next two hours could be getting
fetched and added to the client-side database.

At the very least, even without predictive caching, the data already
displayed could be maintained in the client-side database in case the user
wants to go back to it (not uncommon, I would think, for television
listings).

Now I wouldn't consider doing this on the site I referenced - there's just
too much need for support across browsers and situations. However as an
example I think it holds. I could see other situations where it would be
useful: trade show schedules (where saving the web page would allow for
offline use of that version of the schedule) and other small datasets.

However there are definately some intranet projects that this would fit
excellently in.

But it's definately not for everything. In my mind the dataset would have
to be small enough such that the whole dataset and all the code to
manipulate it would be smaller than the total amount of code passed down in
a session of using the server-side data. It would also have to data that
will most likely be used as a whole - as you said there's no sense in
passing down a whole rabbit if you just want that lucky foot.

I think, like anything, the descision to add this complexity to the
client-side would have to logically defensible - and in most cases it just
isn't.

Jim Davis
Aug 29 '05 #8

P: n/a
"Richard Cornford" <Ri*****@litotes.demon.co.uk> wrote in message
news:de*******************@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
Aug 29 '05 #9

P: n/a
Jim Davis wrote:
"Richard Cornford" <Ri*****@litotes.demon.co.uk> wrote in message
news:de*******************@news.demon.co.uk...
cjl wrote:
I know that it is silly in the age of Google to 'lose' something on
the internet, but I recently checked out a project that had
implemented a database with a subset of SQL in pure client-side
javascript.


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.

Although I agree with you in general I think there are many scenarios where
this could be useful. It really depends on the data in question and the
circumstances of its use, I think.


You raise some interesting scenarios, but in how many of those would you
use SQL to extract and format data from the database/cache rather than
use purpose built routines?

The concept of building a client-side database and SQL-based API is an
interesting exercise, but it's unlikely to have any real use. The main
purposes of SQL are standardisation of a query interface and portability
between database implementations, neither of which seem to be problems
worth fixing in a client-side JavaScript database.

[...]
--
Rob
Aug 29 '05 #10

P: n/a
"RobG" <rg***@iinet.net.au> wrote in message
news:dB*****************@news.optus.net.au...
Jim Davis wrote:
"Richard Cornford" <Ri*****@litotes.demon.co.uk> wrote in message
news:de*******************@news.demon.co.uk...

You raise some interesting scenarios, but in how many of those would you
use SQL to extract and format data from the database/cache rather than use
purpose built routines?


Well... me, personally - probably none. But my lack of use for a tool
doesn't invalidate that tool.

Many people are much more comfortable with SQL concepts than traditional
programming concepts.

For me I'd find this most attractive for the festival scenario. I'm not
sure if I'd use it (the big, overriding issue to me is how large and complex
the API is). IF (and it's a BIG IF) the API was small enough and fast
enough it might be a nice abstraction... but I really doubt it would be
either small enough or fast enough.

But even there I probably wouldn't use it. The actual (server-side)
database is a set of tables (events, venues, times, categories, etc) but on
the client a collection of objects would do just fine. And looping over the
whole collection to display slices of it would be very fast in JavaScript.

I would suspect that any dataset small enough to consider shipping down to
the client would have the same paradox: if the data set is small enough to
store client-side it's probably too small to require SQL to dig into it.
The concept of building a client-side database and SQL-based API is an
interesting exercise, but it's unlikely to have any real use. The main
purposes of SQL are standardisation of a query interface and portability
between database implementations, neither of which seem to be problems
worth fixing in a client-side JavaScript database.


Again... I think the only real gain is a comfortable abstraction. It
definately doesn't solve any previously unsolved problems.

I'm a ColdFusion programmer by trade... we do love our comfortable
abstractions. ;^)

Jim Davis
Aug 29 '05 #11

P: n/a
"lallous" <la*****@lgwm.org> kirjoitti
viestissä:3n************@individual.net...
Hi Kimmo,


I'm glad you found it, but I MUST protest, that revealing the database
structure to end-users (clients) is asking for hacks, especially when the
site also provides the possibility to run queries. That's just like
making a sign for burglar: "Please come here and steal everything we
have, we don't lock doors or have alarms and our dog is actually just a
chihuahua." That's a warm welcome for hackers. What prevents me from
running "DROP DATABASE xyz" from javascript console?


It is a client-side code, whatever you drop, you drop from your
browser/session only.
Nothing affect other users.

It is a mean to store data for the current user. I see this as a nice
companion for DHTML pages.

Ooohh... I was way off then... If it's per user/session then there's no harm
done. :)

--
SETI @ Home - Donate your cpu's idle time to science.
Further reading at <http://setiweb.ssl.berkeley.edu/>
Kimmo Laine <et****************@5P4Mgmail.com>
Aug 29 '05 #12

P: n/a
RobG wrote:
The concept of building a client-side database and SQL-based API is an
interesting exercise, but it's unlikely to have any real use. The main
purposes of SQL are standardisation of a query interface and portability
between database implementations, neither of which seem to be problems
worth fixing in a client-side JavaScript database.


All true, but another purpose of using SQL could be programmer
familiarity.

For example, we created client classes to hide/make-easier local XML
DOM manipulation. But many of our junior programmers are familiar with
SQL, and such an interface could've helped them concentrate more on our
required complex client-side input validation code, rather than
learning a new data access paradigm.

Cheers, Kev

Aug 29 '05 #13

P: n/a
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.
Aug 31 '05 #14

P: n/a

"Richard Cornford" <Ri*****@litotes.demon.co.uk> wrote in message
news:df*******************@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
Aug 31 '05 #15

P: n/a
Jim Davis wrote:
Richard Cornford wrote: <snip>
(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.) <snip> ... . 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.


The FAQ does not limit the discussion to one application context, but it
is not practical to answer questions in a way appropriate for all
application contexts (as there are too many, and a response appropriate
for any one is likely inappropriate (even inadvisable) form many
others). In the absence of information on the context in which a
question is asked it is necessary for respondents to make assumptions
about the context. If all respondents make their own different
assumptions the result is likely to be chaotic, and of little overall
use to a questioner who has a single context in mind (potentially even
harmful).

To avoid this problem the FAQ states the default assumption for the
group, and asks that individuals for whom that default assumption does
not apply state their context (thus avoiding the need for any additional
assumption on the subject). The default assumption (that the context of
use is the general public Internet) has been chosen because it is the
context in which the majority of questions for the group are asked. So
it is the assumption that is most likely to be correct, and saves the
largest number of people form having to explicitly state the context of
their question.

This situation is clearly, publicly stated in the FAQ, and so it is
inappropriate to assume that any other context applies without an
alternative context being explicitly stated beforehand. Any other
behaviour would require that everyone state the context in which they
were using javascript, and so needlessly waste a great deal of
everyone's time. I.E. The default assumption, and the recognition/use of
the default assumption, saves the most time and effort for the largest
possible number of individuals.

Suggestions for realistic alternative strategies are welcome, but seem
improbable.

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

<snip>

Your definition of "no server" appears to involve slightly more servers
than mine does.

Richard.
Aug 31 '05 #16

P: n/a
"Richard Cornford" <Ri*****@litotes.demon.co.uk> wrote in message
news:df*******************@news.demon.co.uk...
Jim Davis wrote:
Richard Cornford wrote: <snip>
(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.) <snip>


I say this with respect: while not in the c.l.j. FAQ it's generally
considered appropriate and courteous to first attempt to resolve such
matters privately. Suffice to say I neither agree with your assumptions
about my comments or with your interpertation of the FAQ in this instance.
<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.

<snip>

Your definition of "no server" appears to involve slightly more servers
than mine does.


You're missing the point... somebody suggested that an application running
in a browser client-side might use a client-side database. You asked "is a
browser a client if there is no server" implying that no server was
involved.

My point is simply that while an application may or may not access a server,
the browser it resides in may very well still be a client in support of that
application. You asked about the browser in that context, I answered.

But we are exploring tangents (which you've already shown an aversion to) so
let's level-set:

Nobody is asking YOU, personally, to suddenly start putting client-side
databases into your applications. We're responding to your stated
assumptions which indicate that such a concept would always, in every
scenario be a bad idea (an assumption which you bolster only with further
assumption.)

In short we're saying "While client-side data storage and SQL may not sound
good to you (or me) it may be useful to some problems for some people." Is
it so very difficult to concede that point?

Jim Davis
Aug 31 '05 #17

P: n/a
JRS: In article <df*********@news4.newsguy.com>, dated Wed, 31 Aug 2005
12:27:25, seen in news:comp.lang.javascript, Jim Davis
<ne********@vboston.com> posted :
"Richard Cornford" <Ri*****@litotes.demon.co.uk> wrote in message
news:df*******************@news.demon.co.uk...
Jim Davis wrote:
Richard Cornford wrote:

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

<snip>


I say this with respect: while not in the c.l.j. FAQ it's generally
considered appropriate and courteous to first attempt to resolve such
matters privately. Suffice to say I neither agree with your assumptions
about my comments or with your interpertation of the FAQ in this instance.


The world in general does not support Tammany-Hall behind-your-back
operations.

If there is something to be said policy-wise about a newsgroup
discussion then it should be said in public, so that others can see and
refute it if necessary.

That section of the FAQ, AFAIK, is in substance Jim Ley's work; if he
had thought such an approach appropriate, ISTM that he would have said
so explicitly. You may take it that the FAQ, although apparently not
now maintained, represents the wishes of the regulars, TL apart.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME ©
Web <URL:http://www.uwasa.fi/~ts/http/tsfaq.html> -> Timo Salmi: Usenet Q&A.
Web <URL:http://www.merlyn.demon.co.uk/news-use.htm> : about usage of News.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.
Aug 31 '05 #18

P: n/a
Jim Davis wrote:
Richard Cornford wrote:
Jim Davis wrote:
Richard Cornford wrote: <snip>
(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.)

<snip>


I say this with respect: while not in the c.l.j. FAQ it's
generally considered appropriate and courteous to first
attempt to resolve such matters privately.


I don't see anything that needs to be resolved privately. Generally (and
excluding matters internal to personal relationships) I think that if
something is worth saying it should be possible to say it in public.
Thus giving third parties an opportunity to express any opinions they
may have on the subject.
Suffice to say I neither agree with your assumptions
about my comments or with your interpertation of the FAQ
in this instance.


That is interesting. The subject of default assumptions has been
discussed many times before but previously the interpretation of the
FAQ's statement has not been disputed. The issues have previously been
whether the default assumption is the correct/appropriate assumption,
and whether is it reasonable to have a default assumption at all.

However, the situation as expressed in the FAQ is likely to stand until
a practical alternative is proposed, and experience suggests that a
practical alternative will not be proposed.

You may, if you like, attempt to answer unqualified questions on the
group in a way suited to each and all contexts in which the question
could be asked, but you will find that the attempt rapidly exhausts you.

Consider someone vaguely asking about interacting with form controls;
their real context might be a public Internet, or a browser specific
Intranet, or scripting an Adobe Acrobat document, or Flash, or
javascript imbedded an any number of arbitrary applications that have
some concept of 'form control'. A complete response would need to be
sizeable, and a large percentage of it would inevitably be irrelevant to
the individual asking the question in their single context. It simply is
not a practical approach, made even less practical by an appreciation of
the full spectrum of possible applications of javascript.

Something has to be assumed (in the absence of specifics in the
question) in order to make responding at all practical. But there are
significant issues in having everyone make their own arbitrary
assumptions. Suppose, for example, that someone wants to conceal chrome
in the current browser instance and a respondent assumes the question
applies to Netscape/Mozilla browsers in a limited set of circumstances
and so proposed the switching of the - window.locationbar.visible,
window.statusbar.visible, etc - properties. The OP then goes of and
tries it running on the local file system and discovers that it works
(at least in the version they are using for testing), and thinks they
have a solution. Only to later discover that their public Internet
context allows no such thing, for security reasons and because the
properties are unknown to most browsers.

Not that there is anything wrong with someone providing an answer to an
unqualified question that is only applicable to a specific browser,
browser version or context of scripting, so long as they say so (and so
don't potentially send an OP off down a blind ally).

But if a single assumption made in response to unqualified questions is
going to be totally arbitrary then every answer needs to state to
context to which it is applicable. The advantage of assuming that one
default context (public Internet use) applies to all questions that do
not express another contexts is that it saves everyone form explicitly
stating the context whenever that default assumption is applicable. Thus
the default assumption should be the context that applies to the largest
proportion of questions asked (to save the effort of the largest number
of people).

As I have said, if a more practical approach is available I (and
probably many others) would like to here about it.
<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.

<snip>

Your definition of "no server" appears to involve slightly more
servers than mine does.


You're missing the point... somebody suggested that an application
running in a browser client-side might use a client-side database.
You asked "is a browser a client if there is no server" implying that
no server was involved.


One of us may be missing the point here, but I was responding to:-

| For that matter, client-only applications can simply use DHTML
| as a display device, and never connect to a server.

In which the use of the word 'only' (implying isolation) in
"client-only" and particularly the words "never connect to a server"
suggest that there is no server involved. I asked whether a browser was
a client when there was no server with the intention of suggesting that
the term "client-only" was a misnomer. The onlyness in the situation
seeming to preclude the client relationship.

Richard.
Sep 4 '05 #19

This discussion thread is closed

Replies have been disabled for this discussion.