3 ms·
The central issue here is trust. If you trust the provider of the url to maintain the link, ensure that it stays alive and pointed to what you expect, then it's
by brettcvz 14y ago
The central issue here is trust. If you trust the provider of the url to maintain the link, ensure that it stays alive and pointed to what you expect, then it's fine.
In the C caching pointers case, the issue is that the system makes no guarantees about the "live"-ness of any prior pointers, whereas on the web this is entirely possible and encouraged (See oft-cited post about "Cool URIs don't change)
- doktrin 14y agoThe central issue here is trust. If you trust the provider of the url to maintain the link, ensure that it stays alive and pointed to what you expect, then it's fine. How can that ever be a realistic expectation over anything but the immediate and short term? Not to mention that in the overwhelming majority of cases the "provider" of a URL is not the party responsible for maintaining it. I have to agree with the parent - unless the recipient of the URL [continuously] validates the source, she is simply asking for trouble down the road.
- BHSPitMonkey 14y agoI don't think I trust any web site in that regard, though. I could even see Google yanking the floor out from under me as a consumer of one of their URL schema.
- icebraining 14y agoIf you didn't trust any web site, you wouldn't click on any link. Trusting a website doesn't mean you have to trust them indefinitely. You can trust that the URL will be kept alive for a certain length of time - minutes, hours, days, etc - and deal with them accordingly.