Dear all, I have to apologize: I had been in touch with Thorben before, and already answered him regarding the “Notes on Implementation” directly, in a private, German email. That was unconstructive! I should have sent it here and saved Reese some work - it seems that this reflects almost 100% what I already wrote to him. Sorry! A few more comments below:
> On Jan 8, 2022, at 4:01 AM, Theresa Enghardt <[email protected]> wrote: > > 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. My view is that this doesn’t need more text in the API document, but the fact that Thorben was led to believe that his implementation conflicts with the API makes me a bit uneasy… I think we should try to stress the abstract nature as much as possible and write somewhere (in the implementation draft, IMO) that concrete implementations might look quite different (perhaps even giving some language-specific examples from the implementations that now exist). > 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? I would also have thought so - I was surprised by this text, which reads as if we demand that Properties are defined by a string. I wonder if there’s something wrong or misleading in the API draft that led Thorben to believe so? > 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. 100% agree as well; in fact I also mentioned Martin’s draft in this context in my private response :-) > > Of course, the above are just one co-author's thoughts, two now :-) Cheers, Michael > 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 _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
