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

[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
> set-ups, etc. But - what about decentralised data storage?: > > -You need some central place which will drive your sync. mechanisms. (In
> 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
> 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,
> ability to work off-line, spooling data to database or directories, not > requiring accepting system to be "live and listening at the time", the
> 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