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

[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
> > (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
> 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
> > 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
> > clients needing a full client-side database. > > Well, here we disagree. I see the FAT (storage) client as the solution.
> central server will store all data (VERY FAT server) and my client will
> my personal view and data extensions on it. Unfortunately the amount of
> increases tremendously. I'm working as a management consultant, each
> 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
> > 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
> a file storing objects, and the object has direct links to releated
> 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-