3 ms·

My point is that once you mandate that, then forever all stores must be architected around providing this web API, based on technology assumptions frozen in la

by zepto 6y ago

My point is that once you mandate that, then forever all stores must be architected around providing this web API, based on technology assumptions frozen in law. Building a P2P or distributed store, not based on a central website, just as an example, would be illegal. This is just one example of how the future would be encumbered forever based on a 90’s software architecture becoming enshrined in law. The web as it is today is not some endpoint in software evolution. A Government mandated API is literally the government regulating software architecture.

mindslight 6y ago
A law would be horribly broken if it said something like "all stores must have a web API". Alternatives of "web stores must have a web API" or "all businesses with a digital UI must have a published API offering the same features" wouldn't succumb to that. That's why I take issue with the word "architecture". If a business has chosen to offer a web storefront, a web API can be supplied right alongside that. There's no need for any "architecture" mandate - the business has chosen the architecture, and the law would mandate accessibility. Also a P2P/distributed store would itself be defined by an open API, making the issue moot.
- zepto 6y ago
  > A law would be horribly broken if it said something like "all stores must have a web API". Alternatives of "web stores must have a web API" or "all businesses with a digital UI must have a published API offering the same features" wouldn't succumb to that. There would have to be a lot more than that. Who would govern API quality, what about service levels, how about authentication and sign up? Data formats, etc. Would these all be up to the vendor? What happens when there is a bug in the API? > That's why I take issue with the word "architecture". If a business has chosen to offer a web storefront, a web API can be supplied right alongside that. No, see above. It just isn’t that simple. > There's no need for any "architecture" mandate - the business has chosen the architecture, and the law would mandate accessibility. Well this isn’t what you said before. > Also a P2P/distributed store would itself be defined by an open API, making the issue moot. Not at all. There is no reason at all for distributed store network would need to have an open API. It could operate in terms of user facing pages for people to interact with - or be like a network of chat bots. You are basing this entire hypothesis on the basis that computer architectures are what you imagine them to be today, which is an invalid assumption.
  - mindslight 6y ago
    > You are basing this entire hypothesis on the basis that computer architectures are what you imagine them to be today, which is an invalid assumption.* It seems to me that you are the one who is pulling in details from today, asserting that they must be incorporated into any law, and then pointing out how that's a bad idea. My lone assumption is a business that provides user-facing software. That's it. With that assumption, I'm arguing for the principle that when a business provides customers a human-targeted "UI", they need to provide a corresponding machine-usable "API" that bypasses the accidental complexity of human interaction. We know there must be a machine-friendly format before the user-friendly format, because the software is itself operating on a machine. >> the business has chosen the architecture, and the law would mandate accessibility. > Well this isn’t what you said before. This is what I said before. Having some type of public API is not "architecture". It's mandating open access to the same thing any front end needs to access anyway. Authentication and sign up: It's a public API, so this is irrelevant for read access. For ordering, the same exact account system as using the web/app UI. You keep ignoring existing implementations, pretending like what I'm saying would require some huge ground-up design rather than tweaks to what already exists. Data formats: The company. If a company is big enough to dictate formats, then they're big enough for developers to pay attention to. After the custom of using aggregators for shopping becomes commonplace, it becomes in their own interest to stick with common formats rather than get left behind. Bugs: The company, while leaving the old "buggy" version in place for some period of time. In general, you seem to be succumbing to the programmers-don't-understand-the-law trap whereby you're imagining that any such law would be useless since a company could just deliberately create an unusable API. But courts see right through those type of "bad faith" approaches.
    - zepto 6y ago
      > It seems to me that you are the one who is pulling in details from today, asserting that they must be incorporated into any law, and then pointing out how that's a bad idea. You say this but then go on to pull in far more detail from today than I have... > My lone assumption is a business that provides user-facing software. That's it. With that assumption, I'm arguing for the principle that when a business provides customers a human-targeted "UI", they need to provide a corresponding machine-usable "API" that bypasses the accidental complexity of human interaction. We know there must be a machine-friendly format before the user-friendly format, because the software is itself operating on a machine. False. Actual machine friendly formats are not the same as the data structures that power UIs. >> the business has chosen the architecture, and the law would mandate accessibility. > Well this isn’t what you said before. >This is what I said before. Having some type of public API is not "architecture". It's mandating open access to the same thing any front end needs to access anyway. As already stated, the front end is not the same thing as an api suitable for clients. Maintaining a stable API is quite different from building a front-end site. > Authentication and sign up: It's a public API, so this is irrelevant for read access. Is it? Front ends often require sign up for read access. Why wouldn’t an API? > For ordering, the same exact account system as using the web/app UI. Wait - I thought your idea was architecture neutral. Why are you talking about the web ui? > You keep ignoring existing implementations, pretending like what I'm saying would require some huge ground-up design rather than tweaks to what already exists. Ahh, so this is just about how things are built today with minor tweaks. > Data formats: The company. If a company is big enough to dictate formats, then they're big enough for developers to pay attention to. Ok, so your law requires people to dictate formats? > After the custom of using aggregators for shopping becomes commonplace, it becomes in their own interest to stick with common formats rather than get left behind. Aggregators owned by whom? Google, Facebook, Amazon? > Bugs: The company, while leaving the old "buggy" version in place for some period of time. Seems like you have just introduced an architectural requirement to be able to run old versions in parallel with new ones. Who determines the person of time? > you're imagining that any such law would be useless since a company could just deliberately create an unusable API. But courts see right through those type of "bad faith" approaches. You are the only one talking about bad faith. I’m simply pointing out that supporting API clients requires architecture that is different from only supporting UI visitors. If you are iterating on the UI frequently, and changing the structures that supports that UI, the by definition you don’t have a stable API unless you engineer one separately. No bad faith needed.

by zepto 6y ago

mindslight 6y ago

A law would be horribly broken if it said something like "all stores must have a web API". Alternatives of "web stores must have a web API" or "all businesses with a digital UI must have a published API offering the same features" wouldn't succumb to that. That's why I take issue with the word "architecture". If a business has chosen to offer a web storefront, a web API can be supplied right alongside that. There's no need for any "architecture" mandate - the business has chosen the architecture, and the law would mandate accessibility. Also a P2P/distributed store would itself be defined by an open API, making the issue moot.

zepto 6y ago
> A law would be horribly broken if it said something like "all stores must have a web API". Alternatives of "web stores must have a web API" or "all businesses with a digital UI must have a published API offering the same features" wouldn't succumb to that. There would have to be a lot more than that. Who would govern API quality, what about service levels, how about authentication and sign up? Data formats, etc. Would these all be up to the vendor? What happens when there is a bug in the API? > That's why I take issue with the word "architecture". If a business has chosen to offer a web storefront, a web API can be supplied right alongside that. No, see above. It just isn’t that simple. > There's no need for any "architecture" mandate - the business has chosen the architecture, and the law would mandate accessibility. Well this isn’t what you said before. > Also a P2P/distributed store would itself be defined by an open API, making the issue moot. Not at all. There is no reason at all for distributed store network would need to have an open API. It could operate in terms of user facing pages for people to interact with - or be like a network of chat bots. You are basing this entire hypothesis on the basis that computer architectures are what you imagine them to be today, which is an invalid assumption.
- mindslight 6y ago
  > You are basing this entire hypothesis on the basis that computer architectures are what you imagine them to be today, which is an invalid assumption.* It seems to me that you are the one who is pulling in details from today, asserting that they must be incorporated into any law, and then pointing out how that's a bad idea. My lone assumption is a business that provides user-facing software. That's it. With that assumption, I'm arguing for the principle that when a business provides customers a human-targeted "UI", they need to provide a corresponding machine-usable "API" that bypasses the accidental complexity of human interaction. We know there must be a machine-friendly format before the user-friendly format, because the software is itself operating on a machine. >> the business has chosen the architecture, and the law would mandate accessibility. > Well this isn’t what you said before. This is what I said before. Having some type of public API is not "architecture". It's mandating open access to the same thing any front end needs to access anyway. Authentication and sign up: It's a public API, so this is irrelevant for read access. For ordering, the same exact account system as using the web/app UI. You keep ignoring existing implementations, pretending like what I'm saying would require some huge ground-up design rather than tweaks to what already exists. Data formats: The company. If a company is big enough to dictate formats, then they're big enough for developers to pay attention to. After the custom of using aggregators for shopping becomes commonplace, it becomes in their own interest to stick with common formats rather than get left behind. Bugs: The company, while leaving the old "buggy" version in place for some period of time. In general, you seem to be succumbing to the programmers-don't-understand-the-law trap whereby you're imagining that any such law would be useless since a company could just deliberately create an unusable API. But courts see right through those type of "bad faith" approaches.
  - zepto 6y ago
    > It seems to me that you are the one who is pulling in details from today, asserting that they must be incorporated into any law, and then pointing out how that's a bad idea. You say this but then go on to pull in far more detail from today than I have... > My lone assumption is a business that provides user-facing software. That's it. With that assumption, I'm arguing for the principle that when a business provides customers a human-targeted "UI", they need to provide a corresponding machine-usable "API" that bypasses the accidental complexity of human interaction. We know there must be a machine-friendly format before the user-friendly format, because the software is itself operating on a machine. False. Actual machine friendly formats are not the same as the data structures that power UIs. >> the business has chosen the architecture, and the law would mandate accessibility. > Well this isn’t what you said before. >This is what I said before. Having some type of public API is not "architecture". It's mandating open access to the same thing any front end needs to access anyway. As already stated, the front end is not the same thing as an api suitable for clients. Maintaining a stable API is quite different from building a front-end site. > Authentication and sign up: It's a public API, so this is irrelevant for read access. Is it? Front ends often require sign up for read access. Why wouldn’t an API? > For ordering, the same exact account system as using the web/app UI. Wait - I thought your idea was architecture neutral. Why are you talking about the web ui? > You keep ignoring existing implementations, pretending like what I'm saying would require some huge ground-up design rather than tweaks to what already exists. Ahh, so this is just about how things are built today with minor tweaks. > Data formats: The company. If a company is big enough to dictate formats, then they're big enough for developers to pay attention to. Ok, so your law requires people to dictate formats? > After the custom of using aggregators for shopping becomes commonplace, it becomes in their own interest to stick with common formats rather than get left behind. Aggregators owned by whom? Google, Facebook, Amazon? > Bugs: The company, while leaving the old "buggy" version in place for some period of time. Seems like you have just introduced an architectural requirement to be able to run old versions in parallel with new ones. Who determines the person of time? > you're imagining that any such law would be useless since a company could just deliberately create an unusable API. But courts see right through those type of "bad faith" approaches. You are the only one talking about bad faith. I’m simply pointing out that supporting API clients requires architecture that is different from only supporting UI visitors. If you are iterating on the UI frequently, and changing the structures that supports that UI, the by definition you don’t have a stable API unless you engineer one separately. No bad faith needed.