Re: [Taps] Early TAPS Implementation in Go, Feedback Welcome

[Theresa Enghardt <[e-mail]>]

Hi Thorben,

Thank you for sharing your TAPS implementation, your feedback, and your 
questions with us!

Please do feel free to open more issues on our Github regarding our 
drafts, especially if you have feedback on draft-ietf-taps-impl based on 
your implementation experience.

With my chair hat on, I'm wondering if you'd be interesting in joining 
our next virtual interim meeting, planned for Wednesday January 26th at 
16:00 UTC, and briefly present your implementation and most important 
questions/challenges?

With my co-author hat on for the rest of this email, I found your "Notes 
on Implementation" [0] an interesting read, and I have some initial 
thoughts:

On the first section, "Asynchronous, Event-driven Interaction 
Patterns": The TAPS documents strive to be independent of any 
language-specific considerations and I don't think that our use of 
"Event" as a basic term in the Interface draft implies the use of an 
actual Event system when mapping the abstract API into a concrete 
programming language.
Appendix A. Implementation Mapping in the Interface document [1], says 
"Actions could be implemented as functions or method calls, for 
instance, and Events could be implemented via event queues, handler 
functions or classes, communicating sequential processes, or other 
asynchronous calling conventions" - I am wondering if this means that 
Events can also be implemented using a construct such as the one 
described in your notes.
Perhaps it does, but I'm wondering if more needs to be said in the document.

To the "Property/Parameter Access and Type Safety" section, I am 
wondering if this is covered by Section 5 in the Interface document, 
e.g., the last bullet point: "Implementations may use other 
representations for Transport Property Names, e.g., by providing 
constants, but should provide a straight-forward mapping between their 
representation and the property names specified here." - Wouldn't this 
cover struct fields, too?

Regarding the last section, "Pre-Establishment", it sounds to me like 
this is an okay way to handle it. In my mind, "should have a list 
available" means there could simply be a piece of documentation listing 
the protocols which can be registered. Does "registering" each protocol 
with the core system mean that there can be different implementations 
for a given protocol, and/or that these can be dynamically added? If so, 
this could be related to the "TAPS Transport Discovery" idea [2] which 
Martin Duke brought to us last year. It is not clear yet whether the WG 
will work on such a discovery mechanism, but I'm still curious if the 
concepts are related.

Of course, the above are just one co-author's thoughts, and I'm happy 
for the others to chime in as well.

Best,
Reese (formerly known as Theresa)


[0] 
https://github.com/netsys-lab/panapi/blob/a982200736ffe81c1f1be750c8df27845442045d/doc/Implementation.md
[1] 
https://www.ietf.org/archive/id/draft-ietf-taps-interface-14.html#name-implementation-mapping
[2] https://datatracker.ietf.org/doc/draft-duke-taps-transport-discovery/