Consider renaming module/repo to something that doesn't mention distributed tracing/instrumentation about swift-distributed-tracing-baggage

[ktoso]

We are going to make a big rename here.

Due to many teams actively using this type in production right now even, and sometimes OUTSIDE of the context of distributed tracing just as a "glorified type-safe typesafe dictionary" we are going to embrace that that's what this type is, and going to call it ServiceContext.

Truth be told, this type wanted to be called this long time ago but it was back then decided that Context was too generic and we picked a tracing only name. Reality has shown us that the type is much more useful and we should not limit its wording and usage to tracing.

Thanks for opening the discussion and I'll do the necessary changes including repo name change

[slashmo]

It would probably still feel a bit weird in the context Johannes was talking about with https://github.com/apple/swift-llbuild2, but how about a rename to swift-instrumentation-baggage? The module name could stay the same (InstrumentationBaggage). Therefore package and module names would be more aligned. Plus, it sounds a bit more generic than swift-distributed-tracing-baggage.

[ktoso]

Once that's done we'll call a 1.0 of this as well as tracing package 🥳

[weissi]

Suggestions:

• type: stays Baggage
• repo: changes to swift-baggage (loses distributed-tracing-)
• module: ideally Baggage too but that causes this issue, swift#62639

So for now probably just BaggageModule and once swift#62639 is solved we can just rename to Baggage and fill BaggageModule with @_exported import Baggage only...

[ktoso]

I’d be okey with that, though we’ll have to do a round of asking people about opinions before we do so.

Technically this type is modeled to be close to https://www.w3.org/TR/baggage/ and https://cs.brown.edu/~jcmace/papers/mace18universal.pdf specifically. But it’s true that the shape or just being a typed dictionary intended to pass metadata around is a common thing, not just instrumentation. This is still in spirit of the Universal Context Propagation baggage paper so I don’t mind saying to use this for propagation in general, though I do believe the focus should be propagating ACROSS process boundaries.

Having that said, it’ll “just work” even if you put things not intended for cross process propagation into baggage because how our tracing types work: they have to know which keys they’re supposed to propagate. So accidental propagation is not going to happen. And propagation of many keys is intended to be solved my registering a multiplex instrument.

Tl;dr; we have to double check this, but it’d be within the spirit of this project, and broaden its usefulness so that might be good.

[ktoso]

Revisiting this before we head towards 1.0 here (in tracing apple/swift-distributed-tracing#99) and... I'm unsure about the renaming to be honest...

Does anyone have strong opinions here @tomerd @weissi ?

Would folks be ok with the names @weissi proposed up-thread?