Re: Proposal for Decoupling and Issues with CXFServlet

[Dan Diephouse <da...@envoisolutions.com>]

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 <eo...@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