clarify cross account subject support

[ripienaar]

Signed-off-by: R.I.Pienaar rip@devco.net

[matthiashanel]

'$KV.' No bucket

[matthiashanel]

'$KV.' only no bucket included.

[ripienaar]

No, I might want to import a bucket MH_FOO as foo in my api space, its arbitrary subjects meaning we cannot assume users will follow some convention. It's a per bucket prefix.

We are not doing anything ADR-19 atm

[matthiashanel]

That we do in a different place

[ripienaar]

What do you mean?

[matthiashanel]

We will support renaming, just not via the prefix setting in the client api.

[ripienaar]

That will leave it non functional for a large section of people.

So again, for what scenario will this proposal not work? I can only assume since you refuse to answer it will work for all cases and we can go ahead and merge this then?

[matthiashanel]

Of course it will work.
I don't think an intermediary step is need.
I am also weary of already planing for backwards compatibility.

You offered the option to remove prefixes that is the option I'd take at the moment.

If this is only until we have cross account implemented in the sever, go ahead and merge.

[ripienaar]

This will stay as a option to support people who craft their own imports/exports however they like.

Once we have server conventions we add another KeyValueOption lets say ImportFromAccount("A") and this configures the whole thing according to the conventions that will land in the server whenever they do.

These 2 options cohabit fine:

• one for those who write their own imports/exports or on older JWT library or on processes that are already docuented and approved and are hard to change or simply dont want to for some reason - they can set a custom prefix of their choosing
• one for our new conventions for those ready to adopt them

This is a gradual move from no conventions, no rules, no macros to having those, offering a solution today and for those who wont/cant adopt the new conventions.

[matthiashanel]

During the last API meeting, I did not pick up on the urgency that is being created here.
I could get behind your suggestion but have one more question:

No, I might want to import a bucket MH_FOO as foo in my api space, its arbitrary subjects meaning we cannot assume users will follow some convention. It's a per bucket prefix.

Would you need this change even if your use case is resolved otherwise?

jetstream: enabled
accounts: {
    A: {
        users: [ {user: a, password: a} ]
        jetstream: enabled
        exports: [
            {service: '$KV.MH_FOO.>'}
        ]
    },
    I: {
        users: [ {user: i, password: i} ]
        imports: [
            {service: {account: A, subject: '$KV.MH_FOO.>'}, to: 'fromA.$KV.foo.>' }
        ]
    }
}

With this, the client should work when you specify an API prefix of fromA and a bin named foo.
Yes the bin name wouldn't be ignored, you'd just have to provide the name that the importer picked.

Someone hand crafting imports in the time between can use that.
This is basically the same level of craftiness required for JetStream at the moment.
Totally fair for someone that wants to rename a bin on the fly.

I would not be surprised about such a behavior.

If this is good enough for your use case, maybe we should stick with the behavior originally outlined and not introduce a different mechanism that would require us to change more than the value of the API prefix.
(Choosing the prefix is something I'd expect to do as part of us establishing the convention)

[ripienaar]

During the last API meeting, I did not pick up on the urgency that is being created here. I could get behind your suggestion but have one more question:

We have Ruby, Python, Java, .Net, JavaScript+Deno+TS, Rust,Go and contracted 3rd parties doing integrations all in flight implementing the version 1 specification. Every time we change something we cause weeks worth of man hours lost. We discussed this in various calls and said the ADR is finished and kicked off the work for these languages.

This is why we decided to freeze the spec, this is why I suggested to you lets add arbitrary prefixes so today we know any user who has something in place - and to be clear, KV is already in production us at large paying customers - that can solve all problems while we work on ADR19. You accepted that proposal and updated the ADR mentioning arbitrary prefixes.

You then set about having various meetings informing teams to NOT implement the ADR, instead saying implement theJetStream context based API Prefix based solution. Why do you have a problem accepting the things you agreed to? Developers who are now rightfully saying what is going on? Why does it keep changing?

Delivering this is now weeks overdue, we are here nit picking over some minor tiny point and we are not helping anyone progress and we are not improving the outcome - neither of these 2 proposals are significantly better. The only difference is yours does not address setups users might have.

You continue to not tell me what is wrong with my proposal while I have shown you the common curtosy to tell you why yours is a worse proposal, what is your actual concerns? Please show me the same curtesy to describe your actual concerns so we can move forward. Giving me alternative proposals is not stating a concern. State your concerns please.

No, I might want to import a bucket MH_FOO as foo in my api space, its arbitrary subjects meaning we cannot assume users will follow some convention. It's a per bucket prefix.

Would you need this change even if your use case is resolved otherwise?

Can you solve this in a different way by dictating users change their configs, of course! Did we tell anyone that they need to configure in this way? We did not. In the absense of conventions, documentation, macros and helpers, we have to support a prefix.

In what way is making $KV. replacable rather than $KV.BUCKET. in $KV.BUCKET.KEY better or worse?

With this, the client should work when you specify an API prefix of fromA and a bin named foo. Yes the bin name wouldn't be ignored, you'd just have to provide the name that the importer picked.

Who told users to configure it this way? Who ensures they always configure it this way? What will error for them when they do it another way? How are they to discover your one golden way of configuring a server?

They have no way to discover any of these TODAY. However a arbitrary prefix will work (you confirmed) while we work on making answers for the above questions.

If this is good enough for your use case, maybe we should stick with the behavior originally outlined and not introduce a different mechanism that would require us to change more than the value of the API prefix. (Choosing the prefix is something I'd expect to do as part of us establishing the convention)

What convention exist today. AGAIN. This is about creating a solution that works TODAY. Not 6 months down the line once ADR19 has been redone, JWT libraries updated, NSC updated, server updated, documentation written, users passing their change control to use our new mechanisms etc.

How does saying "support a future convention" help anyone today?

Please please stop proposing alternatives to this PR. Please state the problem with it so we can refine it.

[matthiashanel]

Other than that the change is ok