The IPA API context gets set when the API gets bootstraped and interrogated (and equality-tested) in a variety of places, for a variety of reasons. We are currently using stringly-typed programming here, prone to typos, and there is no single place where the valid values are defined.
To promote correctness, readability and maintainability we should change to using and enum.Enum to enumerate all possible values of the API context, and ensure that one of those values is always used when bootstrapping the API or interrogating the context.
enum.Enum
This would limit the imagination of 3rd party developers.
The original idea was that there would be maybe 3 contexts to start with: server, client, installer. This may have expanded over the years but these define pretty well the basic methods that IPA uses its own API.
I agree that better documentation is needed both so that 3rd party developers use their own unique strings, or are at least aware of the implications of using the ones that IPA uses.
@rcritten fair enough. But we should at least use an Enum or a bunch of constants for the values we use in IPA, even if we do not restrict use to those values.
@ftweedal sure, there seem to be enough contexts to make it worth while. It may even be possible to pare down the current list as a result of this effort.
Metadata Update from @pvoborni: - Issue set to the milestone: FreeIPA 4.6
Metadata Update from @tkrizek: - Issue set to the milestone: FreeIPA 4.6.1 (was: FreeIPA 4.6)
Metadata Update from @tkrizek: - Issue set to the milestone: FreeIPA 4.6.2 (was: FreeIPA 4.6.1)
Metadata Update from @tdudlak: - Issue set to the milestone: FreeIPA 4.6.3 (was: FreeIPA 4.6.2)
Metadata Update from @rcritten: - Issue set to the milestone: FreeIPA 4.6.4 (was: FreeIPA 4.6.3)
FreeIPA 4.6.3 has been released, moving to FreeIPA 4.6.4 milestone
Metadata Update from @rcritten: - Issue set to the milestone: FreeIPA 4.6.5 (was: FreeIPA 4.6.4)
Login to comment on this ticket.