Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

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