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 -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
