OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] Why XML for Messaging?

[ Lists Home | Date Index | Thread Index ]

Hello David,

We now have CVS and Google. They make it much better than before..

OK I get it.

> Can you expand on this? Frankly some pieces (like server side) are 
> indeed in better shape. On the other hand, the client side is still on the
> darker side....and in shape like a coach potato.

Depends who you talk to I guess.. I would question how much call
there is for traditional "servers" and traditional "clients". 

It's quite insulting for Small/Medium businesses to always be lumped with
the "cheap clients", and the big business be fed an "expensive
server". That's only to impress the boss of the "enterprise". I personally
think people in the smaller businesses need to be given more respect.

These days they are often the clever ones who don't want to put up
with all the crap that goes along with working for a big company. 

Big companies have usually a bad track record on innovations, they score
well on conformity. We cannot necessarily blame their manager, they only do
what their market are asking, not more or not differently. 

I hope that the new model that is taking shape will provide better apps to
small and big business. 

So many of questions...  how to answer..

I think though the best answer is to just try them out for yourself.

This is precisely what I tried to do during all these months in silence,
thinking about these issues and what could be the solutions. I even came to
real solutions, not the best considering my modest means.

> d) Can we improve the experience of users and have at least responsive
> applications like we got in a not so far past with visual basic,
> powerbuilder and other component based development/run-time environments?

Possibly. Just install more RAM and a faster hard-disk. :-)

This is precisely what we have these days. Gigs of hard disk and gigs of
cycles for our CPU. See how wide is the gap between the actual web
technologies reminiscent of the 60s and at the the most of the 70s (the
mainframe era) and the huge resources we have on the clients. Obviously this
status quo won't stay. It simply do not make sense to transform these
processing monsters into dumb terminal. A simple matter of common sense....

I think that what is happening again is a replay of what happened in the
past. A mainframe centric architecture is slowly replaced by a more
sophisticated distributed architecture. Smart servers and dumb clients
cannot stay forever is somebody leverage the power the actual client have.
Microsoft is doing it. IBM seems to be happy with the mainframe centric
architecture or play some card with a java centric one with their new "smart
client architecture" base... simply on java and Sun, trying to find its way
and making money selling servers as do IBM. Around these three giant is
living an entire ecosystem.... They represent the status quo. Microsoft
controls the client, so it is obvious that they will improve it by providing
a declarative language (XAML) for the client and manage the code to the
reduce the cost of ownership by allowing this code to be delivered by HTTP
servers (or other server). So the question now is:

A) When users will see XAML apps and how the latter leverage the power of
their machine, how will they react to classical web apps (mainframe centric
based on a page model with very little processing on the client side). Will
we see the same scenario that we saw earier? You bet we will. It's only that
we (our industry) are memory less and learn very little form history.

B) What will happen of the mainframe centric architecture when people will
discover that they can talk directly to data sources and do not need the
middle tier? a reshuffle of the industry like we saw earlier in the past.

C) What will happen of standards and industry lead recommendations? That's
an open question....

Didier PH Martin


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS