hi Tommy, all, > On 22 Jul 2019, at 19:15, Tommy Pauly <[email protected]> > wrote: > > > >> On Jul 22, 2019, at 6:56 PM, Philipp S. Tiesel <[email protected]> wrote: >> >> Hi, >> >>> On 22. Jul 2019, at 15:09, Tommy Pauly <[email protected]> >>> wrote: >>> >>> An issue we discussed today in the TAPS meeting was whether or not we >>> should add a concept of "profiles" to the Transport Services APIs. An >>> example of a profile is a "reliable, secure, in-order stream"; or >>> "unreliable datagrams". Another way to think of these profiles are as >>> convenient ways to initialize common parameters. >>> >>> One option is described in this PR: >>> https://github.com/ietf-tapswg/api-drafts/pull/328 >>> >>> To help discern the working group's position, I'll try to distill the >>> high-level options here: >>> >>> 1. Add Profiles as a top-level API document concept that modifies how >>> transport properties and/or preconnections are created. (This is PR #328.) >>> 2. Mention in the API document that specific API implementations may expose >>> conveniences and profiles (presumably as a way to initialize >>> preconnections), but do not modify the API or specify an abstract symbol >>> for profiles. >>> 3. Do not mention profiles at all in the API document, but mention >>> something in the implementation document. >> >> I am definitely in favour of option 1. Our implementation experience with >> PyTAPS showed that setting all transport properties necessary to get “UDP >> like service” becomes tedious otherwise. >> I fear not including them in the examples and the core API will result in >> many developers rejecting TAPS as too complex to use. >> The profiles provide a useful convenience to applications (just like the the >> shortcuts properties.prefer(property) instead of properties.add(property, >> prefer)). >> >> In addition, profiles allow us to be less conservative in how we choose the >> defaults for transport properties, i.e., we don’t need the TAPS defaults to >> be TCP compatible as long as the reliable-in-order-stream profile is. > > Speaking not as the person asking the question, but as an individual in the > group: > > I'm pretty strongly against option (1), and prefer (2). I think we should > specify that convenience functions can exist, but I think changing the one > initialization function of the transport properties to take a profile is not > the right move for the API. Everything can be achieved by making the API for > a convenience profile be a layer on top of the existing API.
+1, for the same reasons. > Specifically, these are the differences: > > (1) Exposes an API in which you always pass a profile (or an explicit nil) to > a TransportProperties object; but the TransportProperties *also* lets you set > each of the individual properties after that. I really like the idea of being able to pull a profile off the shelf and then tweak it. It does seem to me that the right model here is "profiles as convenience constructors or copyable constants" -- that model is pretty reasonably implementable as an add-on, without (That's separate from the question of whether profiles are a "mandatory" feature in taps-interface, a suggested feature in an appendix, or something that exists in a different document). Cheers, Brian > (2) Allows implementations to expose an API call to deliver a > TransportProperties that's set up based on a profile, but that isn't the > fundamental constructor. It is implemented by creating a TransportProperties > (TransportProperties()) and then setting the properties internally. > > Thanks, > Tommy > >> >> AVE! >> Philipp S. Tiesel >> >> -- >> Philipp S. Tiesel >> https://philipp.tiesel.net/ >> > > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
