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/
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
