Towards less magic strings.

[Brad Bishop]

On Fri, Sep 15, 2023 at 04:14:57AM -0500, Patrick Williams wrote:
>On Thu, Sep 14, 2023 at 10:33:10AM -0400, Brad Bishop wrote:
>> On Thu, 2023-09-14 at 01:36 -0500, Patrick Williams wrote:
>> >
>> > ## Service Names
>> >
>> > I think it should be rare that you need a hard-coded service name in
>> > your code, since typically you'll want to do some kind of mapper
>>
>> I would actually propose the opposite - we should use mapper lookups as
>> a last resort and prefer hard-coded service names.  Mapper lookups add
>> latency, and require developers to have OpenBMC specific domain
>> knowledge to do something that should otherwise be simple and well
>> documented.  Mapper indirection also prevents the use of dbus
>> activation, which drastically simplifies service dependencies.
>
>I do like dbus activation when we can and do think it would be
>beneficial to transition to it where appropriate.  I don't think
>anything I've added would get in the way (except possibly that
>opinionated statement you quoted here).

I'm glad you agree and I'm glad the work you have done doesn't make that 
harder.

>You can certainly document
>service name(s) in the YAML with the support I've added.
>
>I'm not positive how we get to what you're proposing from where we are at
>though.  There are a good number of dbus interfaces that are anticipated
>to exist in multiple daemons.  Sensors, inventory, software versions.  I
>don't know how "interfaces should live in a single process" meshes with
>support for PLDM, Redfish aggregation, and multi-host designs.

I don't think they need to mesh.  All I am suggesting is that our best 
practices be:

1 - prefer a hardcoded name until...
2 - multiple names become necessary because of some other part of the 
   architecture.

Perhaps my word choice of "last-resort" was too opinionated as well.

Thanks,
Brad