hi,
with no offense meant, isn't the notion of promoting non-browser-like
clients counter-productive to one of the basic benefits of network
programming such as code maintenance and distribution? i certainly
understand that this may be the best solution for some intranet and legacy
apps, but it comes with a significant cost. whether you communicate with
these fat clients using SOAP or any other protocol, it doesn't change the
fact that you have a substantial non-standard code resource on the client
which will require periodic upgrades and bug fixes. browsers remain
frustratingly difficult to program sophisticated UI, but shouldn't we be
focusing more on making browsers better client platforms than scrapping the
benefits of zero client maintenance with custom clients?
Pat Ludwig
Silverstream Software
> -----Original Message-----
> From: Joaquim Carvalho [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, May 08, 2001 8:28 AM
> To: [EMAIL PROTECTED]
> Subject: Re: XSL instead of JSP
>
>
> I think one way to go would be to implement a SOAP layer on top of
> struts.
> SOAP is a protocol to expose the functionality of an application to a
> remote client through the use of XML requests/and answers
> travelling on
> top of http. Typically a SOAP client constructs a remote call to the
> server much in the same way as a web form is filled with
> information in
> a browser. A post of this xml call could be sent to a struts
> app where
> it would be decoded in the same way a form is, creating the
> form beans
> and all that. The struts app them, instead of rendering the answer in
> HTML would render it in XML according to the SOAP answer specs. The
> client application can be done in anything that can write and read to
> http connection.
>
> Check the SOAP project at xml.apache.org to get the idea of the thing
> although that particular project is not directly usefull in
> this context.
>
> Some time ago I though of this and even inquired the list if this
> SOAP/STRUTS idea was interesting but got no feed back and moved to
> other things. My recollection is that it would be easy to
> extend struts
> to recognize a XML post besides of a Form Post and so SOAP
> and Struts
> could be easily mingled.
>
> I have just finished a project of converting a legacy C web app to a
> SOAP/Web app and the result is very encouraging. The same
> code that is
> answering the direct browser requests also handles requests
> from clients
> written in VisualBasic. We even have APSs as XML clients of our app.
>
>
>
> On Monday, May 7, 2001, at 10:24 PM, Mike Williams wrote:
>
> > Guess I'll add my 2 cents :) I'm also researching using XML in the
> > view component of struts.
> >
> > My needs may be a little off from what you're looking at
> though. We
> > have a application that currently runs as a web app.
> However, some of
> > our clients are a bit spoiled to the GUI of a desktop app.
> So, I need
> > to leverage our current expertise in servlets to interact with a
> > desktop application. That's where I hope XML will come into play.
> >
> > The idea is to use Struts as the framework since we will
> probably still
> > have some clients using the web based system. Hey, that's
> the power of
> > the MVC pattern after all. You can easily plug a different
> view in and
> > everyone is happy :)
> >
> > XML will basically be a messaging protocol between the client and
> > server.
