TransportProperties.WithProfile(profile) *is* a constructor, I believe? (Or at least that's what I interpret and suggest). Calling it multiple times creates two different sets of properties. It's just a convenience way, but not the only way.
Thanks, Tommy > On Jul 23, 2019, at 10:35 AM, Philipp S. Tiesel <[email protected]> wrote: > > > >> On 23. Jul 2019, at 09:40, Tommy Pauly <[email protected] >> <mailto:[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 >>> <https://www.ietf.org/mailman/listinfo/taps> >> > > 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] https://www.ietf.org/mailman/listinfo/taps
