[REBOL] Re: XML / dialects
From: petr:krenzelok:trz:cz at: 7-Jan-2002 16:14
Nice concerns, Porter. Here's a cut and paste of my IOS messages to Steve:
Steve: I am stil confused re distributed database. You know - I can imagine
off-line, asynchronous, queue based messaging, being it text files or SOAP/UDDI
services, transfering data = records, but I am still confused of where and how
data should be stored
distributed database also means data duplication, and I can imagine IOS model
working for very lightweight model of data, but without advanced storage
capabilities, advanced replication capabilities, I am not sure it is viable ....
Conference messages e.g. will grow to some unmanageable thousands of them. What
if you want to build knowledge base out of them?
We are starting to think out new regional information system, suited well for
information centre, as well as for kiosks in some future, mobile devices etc.
First I thought of local rebol version, with some generate-on-demand output
capability - simply I thought web site will be just plain and simply kind of
. But once you want ppl to choose some option, create some
queries, you need some logic put on your webserver machine.
So, I am not decided yet of how to start to deal with it. I can't base it purely
on Rebol, as I don't believe Rebol will be available for all the devices, nor do
we have proper View browser integration etc. So, am I better with robust SQL
backend, surrounded with powerfull Apache + Fast-CGI(= nice distribution,
especially in External mode) + Rebol environment, being
service/message/website-generation/whatever based? ....
Now to some of your points:
You raise the issue of complex replication schemes, hardware and app-server
set-ups, etc. But - what about decentralised data storage?:
-You need some central place which will drive your sync. mechanisms. (In the
case of IOS it is cetral IOS server - /Serve).
- you need to back-up the data anyway - I don't believe you will bet on one of
your company PCs, that can potentially meet HD failure or something like that.
- data duplication could mean real death to data validity. In our SAP R2 and
surrounding systems our customer address info was duplicated in 3 or more
systems. The systems can't even talk one to each other - completly mess here ...
But maybe I just anticipate where are you heading your thoughts. For e.g. in our
large enterprise, our programmers are infected by thinking in SAP terms. On-line
processing? Nah, why? Who needs info on-line? We will do it in job? Is it enough
for you to run the job on a daily basis? I don't like such aproach - my vision
- zero latency enterprise:
- Why to be always dependant upon "live" connection?
- Why to wait for the job task to complete?
- messaging is the way imo - asynchronous, small messages based system, with
ability to work off-line, spooling data to database or directories, not
requiring accepting system to be "live and listening at the time", the system
can be in maintanance mode yet still not affecting system sending info ...
... but my vision is still ... uncomplete and unproven ... :-)