Re: [Taps] TCP components

[Michael Welzl <[e-mail]>]

> On 19 Jun 2015, at 14:32, Brian Trammell <[e-mail]> wrote:
> 
> hi Michael,
> 
> continued, inline.
> 
>> On 18 Jun 2015, at 18:44, Michael Welzl <[e-mail]> wrote:
>> 
>> 
>>> On 18. jun. 2015, at 15.56, Mirja Kühlewind <[e-mail]> wrote:
>>> 
>>> Hi Michael,
>>> 
>>>> Am 18.06.2015 um 15:43 schrieb Michael Welzl <[e-mail]>:
>>>> 
>>>> 
>>>>> On 18 Jun 2015, at 10:48, Mirja Kühlewind <[e-mail]> wrote:
>>>>> 
>>>>> Hi Joe,
>>>>> 
>>>>> I believe the approach Michael is proposing is to look at existing APIs as a starting point; not only abstract APIs.
>>>> 
>>>> No, wrong. Only abstract ones from RFCs, I said this before. These things would typically have preceding IETF debate, whereas trying to cover implementations is a huge and probably meaningless endeavour (the bar may be high for adding function calls to an API on system X and low for an API on system Y).
>>> 
>>> Okay, but then I don’t really understand your approach fully. Yes we should document and look at what’s already specified in RFC, however isn’t the goal of taps to actually figure out how to change/extend/improve these APIs? How can we figure out what’s missing/wrong if we only look at what’s already there?
>> 
>> *My* goal is, and has always been, to provide a simpler, general API that is protocol independent.
> 
> +1, though I would at this point say "better" as opposed to "simpler" and "general", with the caveat that i'm not yet sure what better looks like. This gets back to my point about interaction patterns in the previous message, though: if the simpler API provides only stream interaction, or packet sequence interaction, or if it only allows receivers to get data through asynchronous notifications, it will make it hard to support . So maybe we want a better common API for defining the *requirements* of an association, and better TX/RX *APIs* plural, one for each interaction pattern we want to support.

I agree.


>> Note that this is not only for simplicity for ease of use BUT also for the sake of being able to automatize. After all the major goal is to remove the strict binding between applications and a specific protocol choice.
> 
> We share this higher level goal in any case.
> 
>> To be able to do this (documents 2 and 3), we first need a list of the existing services - our toolbox, if you wish (document 1). Figuring out what's missing / wrong about today's APIs (except that they are bound to a specific protocol) has never been *my* major intention, and I certainly don't see that as the goal of this document. I'd be surprised if that's what the charter suggests?! But of course my opinion is only what it is, the charter reflects the consensus...
> 
> I don't think that's in scope for this document, either. The component (and decomposition) work is aimed at figuring out what the available features are, and what (in a "TAPS as glue layer over existing transports" design) the implications of using protocol X for feature Y are. The API work is a bit of a non-sequitur (but also important to note...)
> 
>> All this being said, it can be a nice side-effect of the document (and note that noone knows what a TAPS system will really look like, and how these RFCs will actually end up being used).
> 
> In general, if there's any content in this document that is useful but doesn't fit but we still find useful, we can certainly put it something else.
> 
>> So I'm not strongly opposing the approach you're now following in that I don't see a big issue with there being a list of components - I just think it's not particularly useful for the goal of the document and doesn't really help the group progress towards its goals. I thought that proposing something more systematic with less arbitrariness could make it easier to put everyone in the same boat (in a way: "look, the boat HAS to be like that, there wasn't much choice, sit down please" rather than "sorry I painted it green, I like that color; I can understand you would have preferred a blue boat...").
> 
> I agree. Given, though, that the protocols we're looking at, that they weren't designed from components, it is really not clear to me how to systematically decompose existing protocols without making arbitrary choices as to where to make the cut.

but why decompose?


> (and I wouldn't read too much into the approach we're following -- we're trying to incorporate the input we've taken from discussion on the list into the structure of the document, and as Mirja says, we're completely open to trying other approaches to do that).
> 
> We could take an opposite approach here: jump forward to section 4, define the features we think we want -- this we can do more systematically, because we're only limited by the intersection of the features we want and the features we think we can realistically deploy, as opposed to the history represented by the protocol components -- and then use the components as a check on the feasibility of those features.

Interesting idea - it sounds good to me!

Cheers,
Michael