4 ms·

You don't, unless the owner of the resource says they are and is trustworthy. No amount of code will change that. No, but you have to decide how your code will

by urbit 13y ago

You don't, unless the owner of the resource says they are and is trustworthy. No amount of code will change that. No, but you have to decide how your code will behave if it detects a change. Should it keep a hash and report an error? But that's just a matter of adding an RFC to describe how to mark URIs as naming immutable resources. That's certainly an interesting way to use the word just. You don't strike me as someone who first heard of the IETF yesterday. And besides, we already have an RFC that does exactly that. It's RFC 2616 - use Cache-Control: max-age. Except that - this channel is polluted with crap information, because lots of sites set their cache-control wrong and don't mean it. So you need a new channel that isn't polluted with crap information. Maybe we're agreeing after all. Why does it require completely reworking the Internet infrastructure from scratch? DNS is also not referentially transparent. Nor are HTTP responses signed by DNS identities. When all is said and done, you have a new service by any standards. Why layer the new service (which is much simpler than the old service) over the old ball of mud? If you want to talk to it from the ball of mud, write a gateway.

pdonis 13y ago
you have to decide how your code will behave if it detects a change That decision will depend on the application, and that will be true regardless of how resources are mapped to names. That's certainly an interesting way to use the word just. I agree. :-) But note that I'm making a comparison to inventing a whole new operating system, programming language, etc. Compared to that, getting an RFC through the IETF strikes me as fairly simple. :-) we already have an RFC that does exactly that. It's RFC 2616 - use Cache-Control: max-age. Except that - this channel is polluted with crap information But that's not for the specific purpose of marking resources as immutable; it's overloaded with a number of purposes, which don't always mesh very well. DNS is also not referentially transparent. Maybe this would make more sense to me if I had read more of the papers relating to this, but it seems to me that "not referentially transparent" is a very general term that can mean a number of different things. Do you just mean that the IP address pointed to by an A record can change? Or do you mean that the resource pointed to by, say, "peterdonis.net" can change?
- urbit 13y ago
  Compared to that, getting an RFC through the IETF strikes me as fairly simple. If I had to get the whole new operating system, etc, through the IETF, I might agree with you! You know, all your questions have the same answer. Of course no standard can control the behavior of a remote server. But when you have an environment in which mutability is neither expected nor produced, any violation of immutability is easily recognized as a bug - and (in a highly specified system like Urbit) a very unlikely bug. Whereas whatever conventions you add to the W3 environment that say "this resource is immutable," pretty much everything in that environment is "overloaded with a number of purposes, which don't always mesh very well" - and if the receiving end of a protocol actually treats your conventions as if they were ironclad rules, it's violating Postel's Law. There's just too much "give" in the whole system, and that's a mistake that's much easier to not make in a new system, than to fix in the old one.

by urbit 13y ago

pdonis 13y ago

you have to decide how your code will behave if it detects a change That decision will depend on the application, and that will be true regardless of how resources are mapped to names. That's certainly an interesting way to use the word just. I agree. :-) But note that I'm making a comparison to inventing a whole new operating system, programming language, etc. Compared to that, getting an RFC through the IETF strikes me as fairly simple. :-) we already have an RFC that does exactly that. It's RFC 2616 - use Cache-Control: max-age. Except that - this channel is polluted with crap information But that's not for the specific purpose of marking resources as immutable; it's overloaded with a number of purposes, which don't always mesh very well. DNS is also not referentially transparent. Maybe this would make more sense to me if I had read more of the papers relating to this, but it seems to me that "not referentially transparent" is a very general term that can mean a number of different things. Do you just mean that the IP address pointed to by an A record can change? Or do you mean that the resource pointed to by, say, "peterdonis.net" can change?

urbit 13y ago
Compared to that, getting an RFC through the IETF strikes me as fairly simple. If I had to get the whole new operating system, etc, through the IETF, I might agree with you! You know, all your questions have the same answer. Of course no standard can control the behavior of a remote server. But when you have an environment in which mutability is neither expected nor produced, any violation of immutability is easily recognized as a bug - and (in a highly specified system like Urbit) a very unlikely bug. Whereas whatever conventions you add to the W3 environment that say "this resource is immutable," pretty much everything in that environment is "overloaded with a number of purposes, which don't always mesh very well" - and if the receiving end of a protocol actually treats your conventions as if they were ironclad rules, it's violating Postel's Law. There's just too much "give" in the whole system, and that's a mistake that's much easier to not make in a new system, than to fix in the old one.