[REBOL] Re: XML / dialects
From: pwoodward:cncdsl at: 7-Jan-2002 12:12
Petr -
> 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).
Absolutely true - but it's relatively lightweight (I think it's an Apache
add-on). And, in theory, Reblets and apps deployed on IOS should be able to
function w/o access to the server. Of course, that does mean your copy of
data will be out of sync.
> - 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.
I'm not sure about that. What if the data was transparently replicated to a
few other peers in a group? Say your data was actually (unbeknownst to you)
replicated securely to 5 other desktops in your org. Would that be enough
redundancy?
> - 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 ...
I think there will still be a place for large, centralized data stores. But
not everything needs to run that way.
> "ZLE" - zero latency enterprise:
>
> - Why to be always dependant upon "live" connection?
I think that's where RT is trying to go. In theory (I haven't really seen a
system built on it) IOS should be able to function w/o a live connection.
It'll sync up when it can.
> - Why to wait for the job task to complete?
It shouldn't. The request should go out - and the client should act as a
server with a background task of watching for responses.
> - 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 ... :-)
As is mine, and I'm sure RT has a little ways to go yet in this regard. The
best examples I've seen with this so far have been in Groove (it's a bit
sluggish for my taste) - where a server can be equipped to work as a
gateway
to legacy services. One cool thing is the ability to use the IM
process of Groove to post to a web page (the "user" you message is actually
a bot). Ultimately I see P2P delegating more processing and data redundancy
to the clients - but there will still be centralized services.
- Porter
