[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Need volunteer to draft definition of reliable messaging,wasRE:reliable messaging - hop by hop
Date: Tue, 4 Sep 2001 11:18:15 -0500 From: "David Fischer" <david@drummondgroup.com> On your points, while I don't disagree with any of them per-se, I think many of them would be considered a layering violation if we took them up -- like making sure the message is received by the application. Isn't that BPSS's job? Maybe we need to work on the interface but certainly nothing more. We need to stick strictly to Transport. I agree that we have to stick to the transport layer. What I'm suggesting is that the transport layer includes the *contract* of the transport layer, i.e. the exactly definition of the set of services that the transport layer provides to its caller. We should not have anything to say about who the caller is. But I think we'll find that the only way to coherently describe the transport layer is in terms of a set of services that the transport layer provides and promises to undertake. So I do think it's appropriate to talk about the caller handing a message to the transport layer, and saying "please send this", so that we can define exactly what the transport layer undertakes to do when told to send something. And it's appropriate to say that the transport layer can tell its caller "OK, the message definitely arrived" or "OK, the message did not (and will never) arrive". As such, I still think NRR is MSH only and BPSS is really violating our layer to deal with that. However, I am not sure they do. It looks to me like they simply have true|false flags dictating functionality. Perhaps they only send a signal or set a flag for the MSH level to request/perform the NRR functionality. I agree, that seems to me like the most sensible interpretation.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC