4 ms·

URIs are names for data - but they're not referentially transparent names. Basically, the inspiration for URIs is Unix filesystems, whereas it should have been

by urbit 13y ago

URIs are names for data - but they're not referentially transparent names. Basically, the inspiration for URIs is Unix filesystems, whereas it should have been Git repositories. It's easy to build mutable resources on top of an immutable namespace. Just put the date, change number, or label, in the name. But once you stop being referentially transparent, you can never recover that virginity. There was sort of an attempt to make Cache-Control headers work in HTTP, but they really don't (I speak as a recovering browser developer), and there's just no substitute for everything having an infinite lifetime.

pdonis 13y ago
It's easy to build mutable resources on top of an immutable namespace. Just put the date, change number, or label, in the name. But git repositories don't work this way. Every object in a Git repo is immutable; when I pull a new commit from somewhere, it looks to me like the files in my working copy magically change to the new versions (i.e., that they are mutable), but what's actually happening in the repo is that a set of new immutable objects are added; nothing that was there already changes. This sort of scheme can just as easily be built using URIs (or, for that matter, Unix filenames), so I don't see what the big deal is. You have some URIs (analogous to the filenames in my git working copy) that appear to be mutable resources, but they are implemented on top of other URIs (analogous to the hashes of commits in the git repo) that are immutable resources. All this can be done now, using existing HTTP.
- urbit 13y ago
  Aren't we agreeing vehemently? The problem is when you try to build immutable resources on top of a mutable namespace. How exactly do you know they're immutable? By what convention? What happens to your code if they mutate? Even worse, using a mutable-namespace for immutable bindings, you have two immutable systems talking to each other through a mutable pipe. First the kind of transformation you describe has to be applied, then it has to be reversed. It's a recipe for madness.
  - pdonis 13y ago
    How exactly do you know they're immutable? You don't, unless the owner of the resource says they are and is trustworthy. No amount of code will change that. If you mean, how does the owner of the resource signal that the resource is immutable, yes, I can see that establishing a standard for this would be helpful. But that's just a matter of adding an RFC to describe how to mark URIs as naming immutable resources. Why does it require completely reworking the Internet infrastructure from scratch? using a mutable-namespace for immutable bindings, you have two immutable systems talking to each other through a mutable pipe No, it's a matter of making sure you don't use a mutable namespace for immutable bindings. See above.
    - 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?

by urbit 13y ago

pdonis 13y ago

It's easy to build mutable resources on top of an immutable namespace. Just put the date, change number, or label, in the name. But git repositories don't work this way. Every object in a Git repo is immutable; when I pull a new commit from somewhere, it looks to me like the files in my working copy magically change to the new versions (i.e., that they are mutable), but what's actually happening in the repo is that a set of new immutable objects are added; nothing that was there already changes. This sort of scheme can just as easily be built using URIs (or, for that matter, Unix filenames), so I don't see what the big deal is. You have some URIs (analogous to the filenames in my git working copy) that appear to be mutable resources, but they are implemented on top of other URIs (analogous to the hashes of commits in the git repo) that are immutable resources. All this can be done now, using existing HTTP.

urbit 13y ago
Aren't we agreeing vehemently? The problem is when you try to build immutable resources on top of a mutable namespace. How exactly do you know they're immutable? By what convention? What happens to your code if they mutate? Even worse, using a mutable-namespace for immutable bindings, you have two immutable systems talking to each other through a mutable pipe. First the kind of transformation you describe has to be applied, then it has to be reversed. It's a recipe for madness.
- pdonis 13y ago
  How exactly do you know they're immutable? You don't, unless the owner of the resource says they are and is trustworthy. No amount of code will change that. If you mean, how does the owner of the resource signal that the resource is immutable, yes, I can see that establishing a standard for this would be helpful. But that's just a matter of adding an RFC to describe how to mark URIs as naming immutable resources. Why does it require completely reworking the Internet infrastructure from scratch? using a mutable-namespace for immutable bindings, you have two immutable systems talking to each other through a mutable pipe No, it's a matter of making sure you don't use a mutable namespace for immutable bindings. See above.
  - 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?