cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <eoghan.gl...@iona.com>
Subject RE: Proposal for Decoupling and Issues with CXFServlet
Date Wed, 31 Jan 2007 07:46:18 GMT
 
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
> 

Mime
View raw message