[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
