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 9:08

Petr -
> OK, I know. I also know RT can't do everything themselves. But what about > following conditions?: > > - I am not skilled enough to program standards compliant parser myself > - I don't have enough free time to create one. > - If some manager inside our company looks at rebol site, he/she will not > find any features listed as: "support: XML 1.0, SOAP 1.0, UDDI, ebXML," > etc. etc., so for such manager - Rebol simply does not support the > features, and argument of type - we can implement it ourselves don't > simply count for big boys ... > - we would eventually pay for the features coming with Command update, > along with other databases as PostGress, DB2, etc.
I sort of have to agree with you here - to an extent. However, I also think that the play that RT is making is a little different than the traditional enterprise approach. Stronger XML support would definitely be a "good thing" (tm) - as REBOL will have to play nice with the other kids on the playground. Along with that, both SOAP and UDDI are clearly needed - even if they won't necessarilly be used in their intended fashion (i.e. discovery and usage of some centralized resource), but rather as a mechanism to facilitate distributed computing.
> RT is currently focused on another market - collaborative one. That's > perfect, Rebol has strong potential there, but ... :-)
Here's some of my thoughts on that front - some of you may have already seen these thoughts - but it was a realization that I came to after a lot of work with P2P (Groove, Gnutella, etc). ----- Thoughts Follow ------ I finally figured out a key argument against the centralized "enterprise" model of application building. Decentralization of infrastructure makes sense (esp. for a company like ours who has an ASP-like model) for the following reasons: If you're down that doesn't mean that everyone is down. Just because your website is down, doesn't mean that people cannot still get work done. When your whole application is built around a large, central data store, with a web front end - if it (or any part of it) goes down, you're out of business until it comes back up. Whether it's your web-server, your application server, or your database server, if one of these core systems goes down - the whole application is down, and the people who depend on it to get things done are out of luck. This precipitates a whole ream of expenses to enhance uptime, reliability and availability. Complex backup schemes are implemented. Fail-over hardware is bought and setup. More money is spent on hardware and software that may never be used - unless something crashes. Now that you've got all the extra hardware and software, you've got to hire more people to maintain it - because maintenance will be a nightmare. Multiple web-servers, app-servers, and fail-over database servers. Intrinsic in all of these are some key problems. Replication of data between the live, and fail-over databases is a must. Unfortunately I've never seen a scheme to do this which is uncomplicated, and foolproof. And on the middle, application tier you end up building complex, stateless systems to compensate for a variety of failures - bundling several operations together as an atomic instruction in order to avoid partially committed transactions. Finally on the front-end, web-servers, you have to implement a complex system to enable transferral of session data - or make session data universally available to all web servers. Needless to say, this can be a nightmare! If your data is centralized - then you're vulnerable to a variety of attacks, from hackers to natural disasters. Do you really want to be responsible for your customers data? Why not let them be responsible for their own data? Take yourself out of the loop so that you can concentrate on building new features and a better application without having to be responsible for maintaining all that data. You have to implement complex backup schemes, buy more hardware to support the backups, get specialized software to backup live systems - and you might need fail-over backup systems. Then, you'll need to investigate off-site storage of backups. Disaster recovery plans are also necessary in the face of all that centralization as well. Decentralization, and distribution of computing responsibilities won't allevieate these problems 100%, but they may help reduce them. By distributing the data, and letting the userbase hold onto their own data, you automatically gain multiple backups of that data, without any additional work. This leaves you with the remaining problems: 1> Security. Which is already a problem under the current, de-facto, decentralized computing system. Each users PC currently represents a security risk, and additional entrypoint. Distributed computing doesn't change this. - However, strong encryption of the data exchanged between peers in a distributed system does help reduce risk. - Additionally user understanding that their data is on their system may help improve awareness, and responsibility. 2> Management. Again, already a decentralization problem. Decentralization and distribution will still need a mechanism to allow for global management. - Current computing systems are already distributed (desktop PCs, servers) and already have centralized management tools. - IOS will definitely allow a form of "push" to update reblets, and the client application itself. Without having to go around to every desktop in the org (which is enough of PITA even when everyone is in the same building). I do realize that IOS is going to have some level of server application (the scenario online mentions it). However I'm just guessing but this should be much more lightweight than your traditional Web server, App Server, Database backend. Depending on the nature of the application, I'm sure that those sorts of thing might be required - but in some cases I don't think it really is. And in any case I'm sure that it will eventually be possible to distribute the responsibilities of the server to various clients (sort of having "super" clients that function as partial backups of the server). ----- Thoughts Stop ----- Anyway, when you start to think of REBOL in this fashion (at least as used in the Enterprise) then you start to see why and where RT might be focusing their efforts. - Porter