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] The Browser Wars are Dead! Long Live the Browser Wa rs!

[ Lists Home | Date Index | Thread Index ]

Karl Waclawek wrote:
>...
> 
> I didn't say that there are none, just that the ones 
> I had to implement could not have been done as web client.

I don't think anyone said that every application could be done as a web 
client. Rather, I said that there are great benefits to using a web 
client and that it is inevitable that in the long run, the benefits of 
"Windows clients" and Web clients will be merged in a manner that runs 
across platforms (which is a key benefit of "Web clients").

> ...
> Your examples are exactly those that have simple requirements
> for interaction client/server interaction. Some of those
> we have on the web, simple because - as you said - they
> are easy to deploy.

Fine, so you are agreeing with me. There are certain advantages to the 
Web platform that are hard or impossible to emulate with installed, 
platform-specific technologies. And I am happy to admit that *today* 
there are advantages to installed, platform-specific technologies that 
are hard or impossible to emulate with *today's* Web technologies. And 
perhaps that will always be true to some extent. But the advantages of 
platform-specific technologies will one by one be ported to the Web 
platform so that the proporation of applications deployed on the Web 
will continue to decrease.

> ...
> Our order entry, e-mail and fax (OCR) processing front ends
> are way to heavy on GUI to use a browser. Also, client/server
> interaction is occasionally very fine grained, e.g. you
> select a category in one combo box, and another list refreshes
> accordingly. Don't want to exchange SOAP messages for that,
> our network is stretched as it is.

I agree that those are all factors of *today's technology* that would 
lead one to deploy OS-specific rather than Web apps.

>>>And often - this is a heretic opinion here - I would prefer
>>>DCOM or CORBA over XML for client/middle tier interaction,
>>>simply because XML/SOAP imposes a rather simple communication
>>>model, unless one is willing to re-invent CORBA based on XML.
>>
>>How can the two halves of your sentence be reconciled? If XML can 
>>emulate CORBA then it by definition does not impose a communication 
>>model that is less sophisticated than CORBA.
> 
> 
> Well, following that line of thought, using smoke signals
> would also be as sophisticated as CORBA (just a little slow).

You were the one who used the word "imposes". I wouldn't say that smoke 
signals impose any particular level of sophistication. They do impose 
some performance limitations.

> My point is: everything that is missing compared
> to CORBA I would have to implement myself - or buy some
> bulky third party libraries that seem to exist.
> But then the question is: Why do that if CORBA already
> exists, is mature and free (TAO, OmniORB, MICO).
> And don't tell me it is too difficult to use.
> I have been there, and it is actually surprisingly simple.

If CORBA meets your needs, I will heartily encourage you to use CORBA.

  Paul Prescod





 

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

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