> On 23. Jul 2019, at 10:46, Tommy Pauly <[email protected]> > wrote: > > 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.
I interpreted that differently - WithProfile being a methond of an TransportProperties instance. Anyway – I don’t really mind if the profile is an optional parameter to the primary constructor or whether there is an alternate constructor that takes it as a mandatory argument. For me, the latter is just one way to realise the former in a language that does not support optional parameters and thus an implementer’s choice. > > Thanks, > Tommy > >> On Jul 23, 2019, at 10:35 AM, Philipp S. Tiesel <[email protected] >> <mailto:[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 AVE! Philipp S. Tiesel -- Philipp S. Tiesel https://philipp.tiesel.net/
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
