freesql-discuss — General discussion and development of FreeSQL - please come on in

[Freesql-discuss] baird an bocklogged

[Ladonna P. <yml...@lu...>]

cosmopolitan batch  afghan catkin.  corrosive bernhard conner adherent  colt chimique.  bled carborundum 
darken  chromatography  bedstraw africa   btl  dire bide.   armonk  athena disneyland  armenian archival  accusative    automobile.

[Freesql-discuss] words

[Joel s. <Joe...@a-...>]

ocde

[Freesql-discuss] Kuchwada Madhya Pradesh December

[Lesser <xc...@os...>]

41483

[Freesql-discuss] is ok

[Wojtik3 <wo...@wp...>]

confirm 207260 



---------------------------------------------------------------------
Michael Flatley's "Lord of the dance" już  30 i 31 października
na koncercie w Warszawie! < http://muzyka.wp.pl/imprezy.html?idn=722 >

[Freesql-discuss] (no subject)

[Wojtik3 <wo...@wp...>]

confirm 207260 



---------------------------------------------------------------------
Michael Flatley's "Lord of the dance" już  30 i 31 października
na koncercie w Warszawie! < http://muzyka.wp.pl/imprezy.html?idn=722 >

Re: [Freesql-discuss] Ping?

[Gordan B. <go...@bo...>]

Hi.

> So you want to port FreeSQL to JavaScript, so that the JavaScript "apps"
> can use Freenet as storage?

Yes, that's about the size of it. :-)

> Well, I suppose it's possible--instead of calling Freenet commands on the
> local mahine, the way FreeSQL does in the perl version, you would make
> XML-RPC calls from within the JavaScript to some Freenet node. Assuming JS
> and Freenet support that, I don't see why not.

Well, it wouldn't be XML-RPC to the FreeNet node. I don't think that 
FreeNet nodes support that. It would be more of a case of writing a 
JS library that would talk HTTP to the node in order to upload/download 
data as required.

> One problem I see is that one of the advantages of FreeSQL is performance
> boosting using local caching. If you can't use local files, you are out of
> luck on that one.

It depends on how you look at the problem. The data could be sorted in a 
specific way at insertion time, into different file names and different 
"directories", and then only the relevant data could be retrieved. This 
would be very useful for full-text searching, for example.

In theory, if the application is public, and the data is shared, then the 
more people use it, the less of a problem the performance will become, as 
the nodes start caching the data.

I can certainly see this method working very fast where only one index is 
used on a table. Multiple indices can be implemented, but the there would 
be data duplication. And since most applications spend most of their time 
making use of just one index per table (could be multi-column, of course), 
it isn't really an issue for anything but very large applications with 
very complex tables and relationships.

But if I use the idea of using file naming for fast index searching (say 
convert each indexable key word into an SHA-512 hash), and then use 
cascaded recursive algorithm to perform table joins, it should reduce the 
amount of retrieval work to a bare minimum - even for operations as 
complex as FTS with table joins. Obviously, the less restrictive the 
query, the slower the process.

> The other problem, or question really, is Why do you want to do this in
> JavaScript of all languages? I generally try avoid JavaScript whenever I
> can.

I used to think so until recently, too, but there are a few things that 
have happened since then:

1) Mozilla 1.0+ fully supports DOM.
2) IE 6+ supports DOM sufficiently that the lacking functionality can be 
detected and emulted using wrapper JS libraries living in "user space" (or 
should I say "browser space"?).

Additionally, everybody has a browser nowdays. Not everybody necessarily 
has a Java or .NET VM. JS fits nicely into the web development paradigm, 
and a lot of people know the language. As a language, it is not actually 
that bad - it has a fair amount going for it - especially now there is a 
DOM standard that is addopted.

The FreeNet plug for JS would give the full flexibility of creating a 
secure application that cannot damage the user's machine (because JS is 
bolted down to prevent that), has fully distributed operation (runs in the 
client browser) and has data sharing that is as minimal or extensive as 
required. It would allow for no local disk space requirements - just use 
FreeNet as a big shared, secure and masively redundant file system.

> Another suggestion: Why don't you just use one of the many security holes
> in various JavaScript implementations to gain access to the local file
> system and store the files that way? Just kidding. :)

Because I would rather not depend on users using IE. :-p

> As to your question about indexing and table joins, from a quick look at
> the FreeSQL code, it does do indexing but it doesn't appear to support
> joins as yet.

I've been thinking about this. If a full join is required, then there is 
no choice - at least one table has to be downloaded whole. Slow, but not 
difficult.

However, if some criteria for filtering is specified, i.e.

WHERE MyTable.MyField = 'MyValue'

then MyTable can be selectively retrieved first according to the index on 
MyField.

For the join itself, take the smaller of the two pre-filtered tables 
(according to WHERE statements, if any, defaulting to the one that is 
WHERE filtered, unless some table size metrics can be found), and extract 
unique values of the join fields. Select the values from the table that is 
being joined on, and continue this cascade process until all the joins are 
fullfilled.

Further optimisations can be applied later, but this would deal 
efficiently with a vast majority of cases, and the data storage method can 
help a lot, if for example, you know that all the records that start with 
the letter "a" are in the "a" directory. Of course, the much better way 
would be to isolate key words and use hashes to look for them.

But anyway, this is getting a bit long. I have to look through the FreeSQL 
source code first. :-) Ideally, I would like to see the data 
"storage" formats to be compatible between FreeSQL and what I end up 
implementing in JS...

> Hope that helps, at least a little.

It is always useful to bounce ideas off of someone when deciding on a 
design for an application. :-)

Regards.

Gordan

Re: [Freesql-discuss] Ping?

[Clark F. <cl...@ph...>]

Hmmm.

So you want to port FreeSQL to JavaScript, so that the JavaScript "apps"
can use Freenet as storage?

Well, I suppose it's possible--instead of calling Freenet commands on the
local mahine, the way FreeSQL does in the perl version, you would make
XML-RPC calls from within the JavaScript to some Freenet node. Assuming JS
and Freenet support that, I don't see why not.

One problem I see is that one of the advantages of FreeSQL is performance
boosting using local caching. If you can't use local files, you are out of
luck on that one.

The other problem, or question really, is Why do you want to do this in
JavaScript of all languages? I generally try avoid JavaScript whenever I
can.

Another suggestion: Why don't you just use one of the many security holes
in various JavaScript implementations to gain access to the local file
system and store the files that way? Just kidding. :)

As to your question about indexing and table joins, from a quick look at
the FreeSQL code, it does do indexing but it doesn't appear to support
joins as yet.

eries wrote the code so I don't know much more than you about its
inner workings.

Hope that helps, at least a little.

Clark

On Tue, 10 Dec 2002, Gordan Bobic wrote:

> Well, that's one other person, at least. :-)
>
> I don't suppose you are familliar with the innards of the FreeSQL source
> code?  I'm assesing it's concept for one of my projects, but I am
> concerned about potential performance issues, indexing and table joins.
>
> What I am essentially trying to do is design a distributed client-server
> architecture. The applications would be written in JavaScript, and would
> run as much as possible in the client browser (full DOM compliance
> required). It would make the web browser itself an application platform.
> Obviously, this would not be suitable for all applications, but for most
> office type use (word processing, email), it would be perfectly
> adequate. I have the development of this under way already.
>
> Obviously, there is a problem - there is no way to store or access data
> on the local machine through JavaScript. The solution I am working with
> at the moment is XML-RPC calls to the server "half" of the system, which
> would allow for operations that cannot be performed on the client. This
> can be somewhat limited at times, though, as the user is locked into
> using the services of someone running the server. What I am trying to do
> is use FreeNet as the data storage medium. This would mean that the user
> could securely use the applications through public FreeNet nodes,
> without needing to use the server half of the system.
>
> Obviously, a proper server is still useful for some tasks, but the idea
> of using FreeNet is looking very attractive at the moment. What is
> required for this to happen is a fully JavaScript implementation of
> FreeSQL that would provide an API for using FreeSQL on a public FreeNet
> node as an SQL database server.
>
> Any comments/ideas/suggestions?
>
> I am not afraid of doing the implementation of this myself, but some
> input from other people while I'm looking through the FreeSQL source
> code would be appreciated.
>
> Regards.
>
> Gordan

Re: [Freesql-discuss] Ping?

[Gordan B. <go...@bo...>]

On Tuesday 10 Dec 2002 10:41 am, Clark Freifeld wrote:
> I'm here.
>
> I think the project is in sleep mode, waiting for the heroes of old to
> return and reclaim their rightful place on the throne.

Well, that's one other person, at least. :-)

I don't suppose you are familliar with the innards of the FreeSQL source =
code?=20
I'm assesing it's concept for one of my projects, but I am concerned abou=
t=20
potential performance issues, indexing and table joins.

What I am essentially trying to do is design a distributed client-server=20
architecture. The applications would be written in JavaScript, and would =
run=20
as much as possible in the client browser (full DOM compliance required).=
 It=20
would make the web browser itself an application platform. Obviously, thi=
s=20
would not be suitable for all applications, but for most office type use=20
(word processing, email), it would be perfectly adequate. I have the=20
development of this under way already.

Obviously, there is a problem - there is no way to store or access data o=
n the=20
local machine through JavaScript. The solution I am working with at the=20
moment is XML-RPC calls to the server "half" of the system, which would a=
llow=20
for operations that cannot be performed on the client. This can be somewh=
at=20
limited at times, though, as the user is locked into using the services o=
f=20
someone running the server. What I am trying to do is use FreeNet as the =
data=20
storage medium. This would mean that the user could securely use the=20
applications through public FreeNet nodes, without needing to use the ser=
ver=20
half of the system.

Obviously, a proper server is still useful for some tasks, but the idea o=
f=20
using FreeNet is looking very attractive at the moment. What is required =
for=20
this to happen is a fully JavaScript implementation of FreeSQL that would=
=20
provide an API for using FreeSQL on a public FreeNet node as an SQL datab=
ase=20
server.

Any comments/ideas/suggestions?

I am not afraid of doing the implementation of this myself, but some inpu=
t=20
from other people while I'm looking through the FreeSQL source code would=
 be=20
appreciated.

Regards.

Gordan

Re: [Freesql-discuss] Ping?

[Clark F. <cl...@ph...>]

I'm here.

I think the project is in sleep mode, waiting for the heroes of old to
return and reclaim their rightful place on the throne.

Clark

On Mon, 9 Dec 2002, Gordan Bobic wrote:

> Hello?
>
> Is anybody on this list? It seems very quiet here...
>
> Thanks.
>
> Gordan

[Freesql-discuss] Ping?

[Gordan B. <go...@bo...>]

Hello?

Is anybody on this list? It seems very quiet here...

Thanks.

Gordan