Re: [Taps] On Profiles for TAPS Preconnections

[Tommy Pauly <[e-mail]>]

Yes, I would be happier with suggesting something like TransportProperties.WithProfile(profile), rather than replacing the primary constructor.

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 <[e-mail]> 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 <tpauly=[e-mail]>:
> 
> > On Jul 22, 2019, at 6:56 PM, Philipp S. Tiesel <[e-mail]> wrote:
> > 
> > Hi,
> > 
> >> On 22. Jul 2019, at 15:09, Tommy Pauly <tpauly=[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/taps
> 
> 
> _______________________________________________
> Taps mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/taps