[REBOL] Re: Commercializing Rebol
From: robert:muench:robertmuench at: 15-May-2001 17:43
> -----Original Message-----
> From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]On Behalf Of
> Brett Handley
> Sent: Tuesday, May 15, 2001 12:16 PM
> To: [rebol-list--rebol--com]
> Subject: [REBOL] Re: Commercializing Rebol
> Without knowing your specific requirements my comments can only be general
> (phew :) ).
Hi, no problem. I'm seeking for a broad general approach to solve the
problem.
> I believe 'big' business applications usually have a database because it
> stores the data (usually) in one place thus making the job of
> managing/querying business-wide data easier.
And that's the big disadvantage today. More and more people are becoming
mobile, you don't have a fixed office/cubicle anymore, you move around and
you need your data. Internet access in the fields is still slow and I can't
work online for the whole day, at least not in Europe.
> Apparently Rebol/Express can talk to a database so Rebol/Express
> can act as an application server and talk to the database on behalf of the
> client.
That's how every application is done today. So far OK.
> client no longers talks to the database so the problem of syncing client
> with database becomes irrelevent.
But I don't have access to my data if I can't access the server...
> I don't know if the question is so important because I'm sceptical about
> clients needing a full client-side database.
Well, here we disagree. I see the FAT (storage) client as the solution. The
central server will store all data (VERY FAT server) and my client will have
my personal view and data extensions on it. Unfortunately the amount of data
increases tremendously. I'm working as a management consultant, each client
project needs about 250 MB of space. I'm using a personla knowledge-base,
which is about 2GB in size... and yes, I really need all this stuff.
> Given we are talking about Rebol here. The local store is Rebol or more
> likely a custom dialect. The custom dialect could
> enforce some integrity constraints merely by enforcing certain ordering
> rules in the grammar. These can be checked again
> on submission to the Express application.
I agree. And I'm searching for the Rebol way to do it... I don't like the
idea to fallback to a DBMS system to handle data on the client. But as soon
as a lot of data > 100 MB needs to be handled, fast searching is a must,
etc. I don't see another way.
> I guess there might be data that plain files might not be
> suitable for, but
> I think a "plain" file that is a text file with data structured
> in a dialect could handle a lot of situations.
Hmm... I don't know if it's possible but a self-indexed plain file, which
uses /Rebol functionality to index the file might be cool. Example: We have
a file storing objects, and the object has direct links to releated objects.
We could just read in an object from file and would get the next(), prev()
code with it. Now just call next() and the code to access the next object
will be executed. This is a rolled out index, but how to update it?
> How much data do you *really* need on
> the client at all times for users of your application to be able
> to achieve their objectives?
A lot! Take my knowledge-base, I would like to do a Rebol front-end for it,
of course I want to have my complete knowledge-base, not just a part of it.
> You didn't mention security.
I thought it was enough I mentioned ;-)
> With Rebol the local data could be encrypted
> for security. Some embedded databases might do this but then
> again how many
> do? And XML. What out-of-the-box tools can be embedded into a client side
> application to encrypt local XML stores of data?
Right, I hope it is fast enough to handle all the amounts of data...
> Therefore to get the
> most out of Rebol one should take the Rebol point of view and structure a
> solution accordingly.
Right! And that's what I try to do but I didn't came up with THE solution
(yet). Robert
