[REBOL] Re: Commercializing Rebol
From: petr:krenzelok:trz:cz at: 15-May-2001 19:45
----- Original Message -----
From: "Robert M. Muench" <[robert--muench--robertmuench--de]>
To: <[rebol-list--rebol--com]>
Sent: Tuesday, May 15, 2001 5:43 PM
Subject: [REBOL] Re: Commercializing Rebol
> > -----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.
then you need powerfull replication mechanism .... I think most of what you
discuss is solved by Express - dialect based protocol communication in app
level, synchronisation to local machine to allow you to work even off-line
...
> > 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...
What
is data for you then? Is there any other way? If you need some really
powerfull db solution, you probably use Oracle, DB2 or similar server-side
solution. IF you need your data to be available off-line, you would have to
create mechanism of being able to select what kind of data to replicate. We
use Lotus Notes groupware here and you can choose, which database and when
is replicated. It's kind of incremental replication (even /Express does
that), so ppl just press button before they go off-line and selected
databases are replicated to their replicas on local machine, mostly
notebooks. Then it is app to app logic (just my guess as I don't programm in
LN dev. environment) to use local stored data ...
> > > 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.
ouch, that's pretty high number :-)
> I'm using a personla knowledge-base,
> which is about 2GB in size... and yes, I really need all this stuff.
2GB of data locally? Hmm, I am not sure if it is efficient to solve it via
some local mechanism. What about running db server on your machine then? Or
do you have any concrete mechanism in mind?
> > > 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 it will allow you to abstract the solution - still the same app, just
switch to local store.
On the other hand off-line idea is a little bit flawed imo. The future is
(although I can't know how near future I am talking about :-) to be ALWAYS
connected! It means - you can always replicate your data - it should not
take so much time to do synchronisation with your central DB. I am also not
sure if there is any general aproach. Look at /Link - it downloads it's
conference messages to client, but I can also imagine some areas where you
would not like to do so ...
> > 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?
I don't want to be negative, but we are probably going to reinvent the
wheel. If you need power, let your data be handled by really powerfull
solution. What about several instances of the same app running on your local
system? Are you prepared to solve concurency system in your solution? And
what about transactions? System without transactions can turn into wery
painfull experience. I know that! Never more for really important data - you
need rollback methods implemented etc. etc.
I am not sure there is simple and general aproach of how to solve the
situation ... probably the best one is interfacing to existing db systems
... And you can bet that I would too like to see some very elegant,
lightweight, Rebol based solution to the problem ... :-)
regards,
-pekr-
