Mailing-List: contact dev-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Developers List" <dev@struts.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of craigmcc@gmail.com designates
 64.233.184.205 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references;
        b=S6tec3NrnN1vO/f03OHpaGk4TxhVjwDMbj/vUtueEe+I6ufMLMzvTVKKPp6HCza7S6/rqKo+MQTwBy8Y0bwoL4Eo6g4JobgCaS8//fk27nfugZXXcOwIA5up7nJggofrmzf0ZinkGS4OFv0a4TFWgR4J5d48K83RpRdtjOG5JgE=
Message-ID: <f8b39ace0512272037t71ac4bedp9fac395b9a5bbe03@mail.gmail.com>
Date: Tue, 27 Dec 2005 20:37:00 -0800
From: Craig McClanahan <craigmcc@apache.org>
Sender: craigmcc@gmail.com
To: Struts Developers List <dev@struts.apache.org>
Subject: Re: [shale] Overall requirements for "remoting" feature
In-Reply-To: <dot2l6$rch$1@sea.gmane.org>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_46614_32905478.1135744620403"
References: <f8b39ace0512271832t6411c3aagf80b04458915481e@mail.gmail.com>
	 <dot2l6$rch$1@sea.gmane.org>

------=_Part_46614_32905478.1135744620403
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On 12/27/05, netsql <netsql@pointcast.com> wrote:
>
>
> > PROPOSED REMOTING FUNCTIONALITY - GOALS:
> >
> > The remoting support in Shale should be focused on providing
> > client-technology-agnostic mapping of incoming HTTP requests to server
> side
> > dynamic logic for AJAX-enabled widgets (including AJAX-enabled
> JavaServer
> > Faces components), plus an easy way to serve static resources (from
> either
> > the web application itself or from class loader resources) that the
> client
> > side widgets might require.  This support must operate in either a
> servlet
> > or portlet environment, and require minimal (ideally none in the
> simplest
> > case) configuration at the application level.
> >
>
> Great, but there are other remoting types, like AMF, Soap, etc. Could
> other protocols be pluged in to request and return from chain?


The current remote implementation can already do this.  Nothing changes wit=
h
the proposed implementation, except that you will not be *required* to use
Commons Chain as your implementation technique.

And other "ui" of course other than (short lived I predict)
> JavaScript/DHTML.
> JDNC, Flash components (flash 8.5 has a cool new VM)
> If I plug in the ADF sf.net, could I process flash requests? I don't
> need you to implement it, as long as there is a "plugin" mechanism,
> especially for binary protocols.


The current mechanism, and the proposed mechanism, both support binary
protocols as well ... by virtue of providing you access to an underlying
output stream instead of a writer, which can be used to create the
response.  Indeed, this will be necessary to correctly serve static images
(which cannot be reliably delivered via any sort of text stream) already.

>
> > PROPOSED REMOTING FUNCTIONALITY - IMPLEMENTATION STRATEGY:
> >
> >
> > * (Optional) alternative dynamic execution mapping to execute a Commons
> > Chain command
> >   (essentially equivalent to the current functionality, and/or a tie-in
> to
> > Struts Action Framework 1.3.x
> >   type processing logic).
> >
> > * (Optional) alternative dynamic execution mapping to execute an XWork
> > action (essentially
> >   equivalent to what WebWork currently does for mapping incoming URLs t=
o
> > business logic).
> >
>
> Great that WebWork and "Clasic" are in there or could be pluged in.
> Ideally Shale is JSF centric but allowed other view types (and remoting
> protocols)


That's definitely an advantage of adding this particular level of
absraction.  It lets you mix and match server side technologies for the
types of responses you need for particular URL patterns.

.V


Craig

------=_Part_46614_32905478.1135744620403--