3 ms·

With two-level naming you still have the squatting problem of the top-level names. It's just now a fight over who owns `oracle/*`. And if you say just use GitH

by pornel 5y ago

With two-level naming you still have the squatting problem of the top-level names. It's just now a fight over who owns `oracle/*`. And if you say just use GitHub user names, you're merely relying on GitHub's support staff to sort it out for you (they're not magic, they have the same problem).

merb 5y ago
> And if you say just use GitHub user names use domains? like java does for over 20 years?
- nicoffeine 5y ago
  This is one of the things that makes me think Deno will ultimately win: Deno Goals: Simplify the module system - No attempt at compatibility with existing Node modules. - Imports are relative or absolute URLs ONLY. (See Semantic Versioning) - Imports must provide an extension. - Remote URLs are fetched and cached indefinitely on the first load. Only if the --reload flag is provided will the resource be fetched again. - Vendoring can be done by specifying a non-default cache dir. https://tinyclouds.org/jsconf2018.pdf https://tinyclouds.org/jsconf2018.pdf
- kryptiskt 5y ago
  It has worked terribly, software often live longer than organizations or can easily change hands. And then we get the absurd directory structures, where half the code lives in com/oldcompanyname and half in com/newcompanyname and related code can be far away. Even Sun went away and left nothing but a bunch of legacy package names.
thaumasiotes 5y ago
> With two-level naming you still have the squatting problem of the top-level names. It's just now a fight over who owns `oracle/*`. The same way that Java packaging is nothing but a big fight over who owns "com.*"?
- pornel 5y ago
  dot-com domain squatting is the OG name squatting. Everything under dot-com is taken. Even for new TLD names there is a bidding process. Domains are not that great for project identifiers. Domain ownership is not permanent, but project identifiers should be.
  - thaumasiotes 5y ago
    > Domains are not that great for project identifiers. I tend to agree. But the fact remains that you don't see fights over namespacing in Java even though everyone uses the same top-level space. I can't see how the claim "you still have the squatting problem of the top-level names. It's just now a fight over who owns `oracle/*`" holds any water. > Domain ownership is not permanent, but project identifiers should be. Package names aren't actually linked to domain ownership. There's nothing stopping me from releasing software under com.oracle.
    - swsieber 5y ago
      > It's less difficult (though still far from easy) to handle name squatting on organization/corporate names as qualifiers for packages than to try and prevent name squatting on package names. So we're back to fighting who owns "com.oracle"? It seems like no matter the approach taken to validating namespace ownership there's some drawback.
      - thaumasiotes 5y ago
        No. There is no fighting over who owns com.oracle. There's nothing stopping you from releasing software in the com.oracle namespace, but when you do, either you are Oracle or you are falsely claiming to be Oracle. Avoiding accidental collisions just isn't the same problem as validating a potentially fraudulent claim of identity. Namespacing solves the first problem; it's not intended to address the second, and doesn't.
  - paulryanrogers 5y ago
    IIRC, Microsoft apps can use a UUID. Which seems clever and future proof, so long its v4.
Denvercoder9 5y ago
It's usually clearer who has the right to a given name though. For example, in a flat namespace any dozen competing AWS clients can claim `aws`, while in a two-level hierarchy its clear that that namespace belongs to Amazon.
- OJFord 5y ago
  ..unless one of the dozen competing AWS clients claims that namespace first? I think (verified) domains are the way to go, with some small whitelist of 'identity providers', so you could use say com.github.ojford, verifying it by logging in with GitHub OAuth rather than DNS record.

by pornel 5y ago

merb 5y ago

> And if you say just use GitHub user names use domains? like java does for over 20 years?

nicoffeine 5y ago
This is one of the things that makes me think Deno will ultimately win: Deno Goals: Simplify the module system - No attempt at compatibility with existing Node modules. - Imports are relative or absolute URLs ONLY. (See Semantic Versioning) - Imports must provide an extension. - Remote URLs are fetched and cached indefinitely on the first load. Only if the --reload flag is provided will the resource be fetched again. - Vendoring can be done by specifying a non-default cache dir. https://tinyclouds.org/jsconf2018.pdf https://tinyclouds.org/jsconf2018.pdf
kryptiskt 5y ago
It has worked terribly, software often live longer than organizations or can easily change hands. And then we get the absurd directory structures, where half the code lives in com/oldcompanyname and half in com/newcompanyname and related code can be far away. Even Sun went away and left nothing but a bunch of legacy package names.

thaumasiotes 5y ago

> With two-level naming you still have the squatting problem of the top-level names. It's just now a fight over who owns `oracle/*`. The same way that Java packaging is nothing but a big fight over who owns "com.*"?

pornel 5y ago
dot-com domain squatting is the OG name squatting. Everything under dot-com is taken. Even for new TLD names there is a bidding process. Domains are not that great for project identifiers. Domain ownership is not permanent, but project identifiers should be.
- thaumasiotes 5y ago
  > Domains are not that great for project identifiers. I tend to agree. But the fact remains that you don't see fights over namespacing in Java even though everyone uses the same top-level space. I can't see how the claim "you still have the squatting problem of the top-level names. It's just now a fight over who owns `oracle/*`" holds any water. > Domain ownership is not permanent, but project identifiers should be. Package names aren't actually linked to domain ownership. There's nothing stopping me from releasing software under com.oracle.
  - swsieber 5y ago
    > It's less difficult (though still far from easy) to handle name squatting on organization/corporate names as qualifiers for packages than to try and prevent name squatting on package names. So we're back to fighting who owns "com.oracle"? It seems like no matter the approach taken to validating namespace ownership there's some drawback.
    - thaumasiotes 5y ago
      No. There is no fighting over who owns com.oracle. There's nothing stopping you from releasing software in the com.oracle namespace, but when you do, either you are Oracle or you are falsely claiming to be Oracle. Avoiding accidental collisions just isn't the same problem as validating a potentially fraudulent claim of identity. Namespacing solves the first problem; it's not intended to address the second, and doesn't.
- paulryanrogers 5y ago
  IIRC, Microsoft apps can use a UUID. Which seems clever and future proof, so long its v4.

Denvercoder9 5y ago

It's usually clearer who has the right to a given name though. For example, in a flat namespace any dozen competing AWS clients can claim `aws`, while in a two-level hierarchy its clear that that namespace belongs to Amazon.

OJFord 5y ago
..unless one of the dozen competing AWS clients claims that namespace first? I think (verified) domains are the way to go, with some small whitelist of 'identity providers', so you could use say com.github.ojford, verifying it by logging in with GitHub OAuth rather than DNS record.