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 <[EMAIL PROTECTED]> 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
