Closed bgavrilMS closed 10 months ago
Any reason we don't do BrokerOptions
similar to what we do in .NET? What way we don't need to implement 3 extra property setters?
@localden : It's not entirely clear to me how the .NET version works or how it's meant to scale with more operating systems. I see BrokerOptions being used like this in a few place in the .NET codebase: pcaBuilder.WithBroker(new BrokerOptions(BrokerOptions.OperatingSystems.Windows)
To my Java brain, it seems like BrokerOptions has a constructor that either takes in one OS at a time, or that BrokerOptions.OperatingSystems
will in some way be updated to have every permutation of OS choices (like BrokerOptions.OperatingSystems.WindowsAndLinux
or something). There's also what looks like bit-based flags being used to track OS options, which isn't a common thing in Java.
The builder style that Bogdan suggested here and used throughout the rest of the library is more of what Java customers would be used to. I could always rename 'builder' to 'brokerOptions' to get the naming closer (Broker.brokerOptions()...
), but I'm pretty sure that goes against some Java standards.
@Avery-Dunn I'd definitely lean more on idiomatic Java constructs here, so if bitwise flags are not common in the language then maybe this is not the right approach. That being said, won't we be able to use something like EnumSet
here?
I haven't used EnumSet much, but if we use it then I believe the customer's code would be something like this:
Broker broker = new Broker(EnumSet.of(OsOptions.WINDOWS, OsOptions.LINUX, OsOptions.XYZ));
(and then we have some extra logic in the Broker
constructor to parse that EnumSet/use it throughout the code)
If that's similar to how .NET plans to do it then I'd support going with that option. My only concern would be that it's introducing a different style of object creation and customers don't like when things are different, however that shouldn't be too big of a deal since this API is part of a brand new package anyway.
Yeah, the default builder pattern is better then @Avery-Dunn - I approved the PR.
MSAL client type
Public
Problem Statement
https://learn.microsoft.com/en-us/entra/msal/dotnet/acquiring-tokens/desktop-mobile/wam
Current API
Proposed API
Thoughts on the above @localden and @Avery-Dunn ?