[REBOL] Re: Commercializing Rebol
From: brett:codeconscious at: 15-May-2001 20:16
Hi Robert,
Just want to make comment about the data.. comments interleaved....
> 2. Data storage
> > I have been thinking about this for quite some time now.
I've given this some thought as well - though it was in the context of a
specific application.
Without knowing your specific requirements my comments can only be general
(phew :) ).
> I'm not sure if it
> will be possible to create 'big' business applications without using a
> database. If a database is needed, than how do we sync this with the
client?
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.
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. The
client no longers talks to the database so the problem of syncing client
with database becomes irrelevent. Interestingly this solution solves two
problems created by the client-server (2 tier) "solution". It increases
security of the database and decreases deployment problems of client-side
database drivers.
> Is the database needed on the client too? How do we install the DB, etc.?
>
> Replicating databases is something I don't like. Rebol/Express has a nice
> syncing feature for all kind of files. Will this concept be able to handle
> databases too? I don't think so (yet). How do we handle database schema
> changes?
>
I don't know if the question is so important because I'm sceptical about
clients needing a full client-side database. I know embedded databases exist
but I suspect that their existence is a lot to do with the existence of
database manipulation controls of RAD tools. A number of people have
proposed using XML as a local store of data on the client - and thus we see
an evolution of the focus in RAD tools to encompass XML as a local store.
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.
> Will it be possible just to use plain files for all kind of data? Depends
on
> the data-size. Currently Rebol is reading in all the data from a file.
What
> about 500 MB of data? Reading it sliced in pieces? How to search etc.
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. Yes data size could be an issue but it
really depends on your application. 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?
You didn't mention security. 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? No doubt people are solving
this problem but just thought I'd throw up the "Beware of Nasty Thing" sign.
:)
> IMO this is a basic problem if you want to use Rebol for business
> applications. At the moment we have to handle the problem like in all
other
> languages.
>
I agree and respectfully disagree. I believe Rebol looks at the world
differently from how other languages look at the world. Therefore to get the
most out of Rebol one should take the Rebol point of view and structure a
solution accordingly. I think a big trap is to emulate using Rebol a
solution structure that accommodates by design the strengths and weaknesses
of another technology. (I hope that makes sense - I had to re-read it
twice...) So yes Rebol may be difficult if one tries to solve the problem
in the same way that one would with other languages, but I suggest there is
no difficulty at all if one steps back and asks "how does Rebol solve this
problem elegantly?"
I suggest pulling out the old Data Flow Diagrams again (with Rebol they gain
new value) and looking hard at what goes where and why.
Thanks for initiating an important discussion.
Brett.