cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <...@envoisolutions.com>
Subject Re: Proposal for Decoupling and Issues with CXFServlet
Date Fri, 02 Feb 2007 18:01:34 GMT
Eoghan, its better but I'm still not keen on f the APIs as they stand at
all.

- Dan


On 1/31/07, Glynn, Eoghan <eoghan.glynn@iona.com> wrote:
>
>
> Hi Dan,
>
> I've had a shot at simplifying the API encountered by transport writers,
> by factoring out the common transport logic into abstract base conduit
> and destination classes ... in such a way as to ensure that writers of
> non-decoupled transports are *completely* insulated from the decoupled
> connection and partial response logic.
>
> Does this change address your concerns about transport API complexity?
>
> Cheers,
> Eoghan
>
> > > > > > Making the
> > > > > > transports very complex to write is also bad.
> > > > >
> > > > > Again frankly I don't see the Destination.getBackChannel()
> > > > semantics
> > > > > as being so difficult to understand.
> > > > >
> > > > > And certainly IMO this API doesn't make transports very
> > complex to
> > > > > write.
> > > >
> > > >
> > > > I've spoken to several people who have worked on writing
> > transports
> > > > and they (and myself) think otherwise.
> > >
> > > Well I ain't a lawyer :), but hearsay proves nothing ... so
> > if these
> > > transport writers want to contribute to the debate, let
> > them speak up
> > > for themselves and demonstrate their locus standi.
> > >
> >
> > Not all of them are subscribed to this list. Although some of
> > them are and they should speak up.
> >
> > - Dan
> >
> > --
> > Dan Diephouse
> > Envoi Solutions
> > http://envoisolutions.com | http://netzooid.com/blog
> >
>



-- 
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message