> On 23. Jul 2019, at 09:40, Tommy Pauly <[email protected]> wrote: > > Yes, I would be happier with suggesting something like > TransportProperties.WithProfile(profile), rather than replacing the primary > constructor.
This has several drawbacks and makes things more complicated: - We need to define what should happen when TransportProperties.WithProfile(profile) is called multiple times - We need to define whether TransportProperties.WithProfile(profile) should override properties that have been set using TransportProperties.add(property, value) - Implementations could choose to do this differently. Having the profile only in the constructors avoids these, as the behaviour is 100% clear - the profile sets the defaults, everything can be overridden afterwards. Also it makes clear that one can only specify a single profile. > To the point of trimming down the API, I do think that it may be good to only > choose one between options like this: > > * properties.prefer(property) > * properties.add(property, prefer) > > The API prescribed by this document is abstract, and needs to give freedom to > implementations to make things elegant in their particular languages. > > What about having an appending, that's non-normative and not required for RFC > compliance, that describes suggested conveniences, such as > "properties.prefer()" and the concept of convenience profiles? > > The point is, if you wanted to have the minimal implementation of a TAPS > implementation that made it possible to let applications do what they need > over TAPS, you wouldn't necessarily need to implement these conveniences, > since they don't add any new capabilities, but instead are semantic sugar. > > Thanks, > Tommy > >> On Jul 23, 2019, at 9:34 AM, Max Franke <[email protected] >> <mailto:[email protected]>> wrote: >> >> I wonder if this argument is more because at the moment profiles are handed >> over as a parameter on creation of the properties and not about the >> existance of properties in general. >> Maybe another solution would be a call along the lines of >> TransportProperties.WithProfile(profile) , similar to what we already have >> with WithService on the endpoints? >> As Philipp said, there are already convenience features in other places of >> the API which should be removed if we agree on keeping the complexity to the >> bare minimum for the core interface. >> >> Best regards, >> Max >> >> Am 22.07.2019 19:15 schrieb Tommy Pauly <[email protected] >> <mailto:[email protected]>>: >> >> > On Jul 22, 2019, at 6:56 PM, Philipp S. Tiesel <[email protected] >> > <mailto:[email protected]>> wrote: >> > >> > Hi, >> > >> >> On 22. Jul 2019, at 15:09, Tommy Pauly <[email protected] >> >> <mailto:[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 >> >> <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/ <https://philipp.tiesel.net/> >> > >> >> _______________________________________________ >> Taps mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/taps >> <https://www.ietf.org/mailman/listinfo/taps> >> >> _______________________________________________ >> Taps mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/taps > AVE! Philipp S. Tiesel -- Philipp S. Tiesel https://philipp.tiesel.net/
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
