> 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. 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. (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
