Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Choosing between names and identifiers in URLs

cloudplatform.googleblog.com

Post reply on HN
Print view View original

111–120 of 157 posts

Re: Choosing between names and identifiers in URLs

#111

Post by rz2k »

sgentle wrote: post #85

The root of the issue here is that URLs are trying to be human-meaningful and machine-meaningful at the same time, but those requirements are fundamentally incompatible. Humans work well with ambiguity and context. You know that when your coworker says "Bob's birthday is this weekend" you know she means her husband Bob, not Bob from accounting who nobody likes. And you even prefer that system to having an unambiguous…

I don’t disagree with your point, but aren’t there languages that do take into account the context in which functions are called in addition to the parameters and namespaces?

Both R and Perl seem like ones where it wouldn’t be extremely strange for the function to also look back to the context of the calling function. Then it could find out if the two parties had an affinity for this person, and whether it was a conversation about something like figuring out an excuse to miss a party or one like finding a gift in order to which Bob.

Re: Choosing between names and identifiers in URLs

#112

Post by Banthum »

ballenf wrote: post #100
sgentle wrote: post #85

The root of the issue here is that URLs are trying to be human-meaningful and machine-meaningful at the same time, but those requirements are fundamentally incompatible. Humans work well with ambiguity and context. You know that when your coworker says "Bob's birthday is this weekend" you know she means her husband Bob, not Bob from accounting who nobody likes. And you even prefer that system to having an unambiguous…

> Machines, on the other hand, hate ambiguity and context. When I ask my car to call my wife using only her first name, it suggests a list of 3 people who I'm not even sure how they got in my contacts list. Siri, on the other hand, gets it right every time with the exact same request. I wouldn't say my car hates ambiguity, the programmers failed to bridge the gap to human/machine interaction and meet the person halfw…

One thing that worries me about computers working with all that contextual information is that they then need to know all that information.

And since computing is so centralized these days, this means that whatever company made the software needs to know that context about you too.

There's something to be said for computers staying dumb. I'm okay with my co-workers knowing my social graph well enough to recognize my spouse's first name by context. I'm not okay with faceless corporations or governments having that same information.

Re: Choosing between names and identifiers in URLs

#113

Post by DelightOne »

> You also need to be careful about how you store your identifiers—the identifiers that should be stored persistently by the API implementation are almost always the identifiers that were used to form the permalinks. Using names to represent references or identity in a database is rarely the right thing to do—if you see names in a database used this way, you should examine that usage carefully.

What does this mean? Is it just to say don‘t use the name hierarchy but rather the permalink-key as identity in the database?

Re: Choosing between names and identifiers in URLs

#114

Post by saghm »

derefr wrote: post #91
sgentle wrote: post #85

The root of the issue here is that URLs are trying to be human-meaningful and machine-meaningful at the same time, but those requirements are fundamentally incompatible. Humans work well with ambiguity and context. You know that when your coworker says "Bob's birthday is this weekend" you know she means her husband Bob, not Bob from accounting who nobody likes. And you even prefer that system to having an unambiguous…

> "Bob-4592-daring-weasel-horseradish" You could easily have a bijective encoding at a frontend proxy that translates between the above and e.g. > "4592-13f7-de41-203a" (i.e. discards the descriptive part of the slug, and then reverses the unique words back into their index-positions in the same static 64k-word dictionary used for generation, resulting in a regular UUID.)

That doesn't solve the issue that neither of those are human-friendly, which was the point as in understood it

Re: Choosing between names and identifiers in URLs

#116

Post by kalleboo »

hire_charts wrote: post #49
nayuki wrote: post #34

The article talks about referring to resources by using URLs containing opaque ID numbers versus URLs containing human-readable hierarchical paths and names. They give examples like bank accounts and library books. This problem about naming URLs is also present in file system design. File names can be short, meaningful, context-sensitive, and human-friendly; or they can be long, unique, and permanent. For example, a…

A long time ago, around when I was first taking systems programming courses, I had this vision for a filesystem and file explorer that would do exactly what you say. I imagined an entire OS without any filepaths for user data (in the traditional, hierarchical sense). My opinion (both now and back then) was that tree structures as a personal data filing system almost always made more of a mess than it actually solved.…

Part of that is kind of what Apple has been going for the past couple of years with macOS, even though they haven't gone all onboard by removing the hierarchical part (since there is so much legacy software and users would revolt).

A new user profile will come with a prominent "All my files" live search shortcut that just shows all your files in a jumble sorted by when you last used them. Then they expect you to search and filter through them by metadata (which is automatically extracted/indexed by Spotlight). Then you can save these searches/filters as saved searches which are live-updating virtual folders.

Re: Choosing between names and identifiers in URLs

#117

Post by kalleboo »

always_good wrote: post #66
mjevans wrote: post #61

Earlier quoted context omitted.

In the most technical sense both are searches encoded in to a URI form. The search for the (hopefully) GUID just happens to be for a specific mechanical object, while the other is describing the taxonomic categorization of what a matching item would look like.

Though their "/search?kind=book&title=moby-dick&shelf=american-literature" example is fundamentally different in that all filters (being URL query parameters) are optional and can be arbitrarily combined. I didn't quite understand the point of the hierarchal "search URL" when you have the /search one implemented, and they go on to say you could implement both if you have the time and energy.

The Internet Archive WayBack machine kind of has an optional filter in a traditional URL scheme - you can replace the date in a WayBack machine URL with an asterisk as a wildcard and you'll get either the only entry it can find or a list of dates

https://web.archive.org/web/20000831072728/http://charlotte....

vs

https://web.archive.org/web/*/http://charlotte.acns.nwu.edu:...

Re: Choosing between names and identifiers in URLs

#118

Post by ballenf »

Banthum wrote: post #112
ballenf wrote: post #100

Earlier quoted context omitted.

> Machines, on the other hand, hate ambiguity and context. When I ask my car to call my wife using only her first name, it suggests a list of 3 people who I'm not even sure how they got in my contacts list. Siri, on the other hand, gets it right every time with the exact same request. I wouldn't say my car hates ambiguity, the programmers failed to bridge the gap to human/machine interaction and meet the person halfw…

One thing that worries me about computers working with all that contextual information is that they then need to know all that information. And since computing is so centralized these days, this means that whatever company made the software needs to know that context about you too. There's something to be said for computers staying dumb. I'm okay with my co-workers knowing my social graph well enough to recognize my…

Very good point. Can't disagree with you. I am ok, however, with a contacts system letting me specify a single name nickname that it prioritizes in matching / searches.

And I'm probably also ok with the computer knowing as much about me as my cellular provider does, since all that is probably hoovered up already. Why should Siri be dumber than the feds?

To take this further afield, it would be interesting to interact with a "smart" assistant that only learned from info likely to be accessible to third party law enforcement and/or aggregator, as a demonstration of the risk & power.

Re: Choosing between names and identifiers in URLs

#119

Post by pls2halp »

hire_charts wrote: post #49
nayuki wrote: post #34

The article talks about referring to resources by using URLs containing opaque ID numbers versus URLs containing human-readable hierarchical paths and names. They give examples like bank accounts and library books. This problem about naming URLs is also present in file system design. File names can be short, meaningful, context-sensitive, and human-friendly; or they can be long, unique, and permanent. For example, a…

A long time ago, around when I was first taking systems programming courses, I had this vision for a filesystem and file explorer that would do exactly what you say. I imagined an entire OS without any filepaths for user data (in the traditional, hierarchical sense). My opinion (both now and back then) was that tree structures as a personal data filing system almost always made more of a mess than it actually solved.…

If you were new to modern macOS(and iOS with the Files app) you might end up with something similar. Applications dump things in the main Documents folder(with user chosen names, but those are necessary metadata). You can then tag items with various labels(essentially adding more metadata), and everything is searchable through spotlight of the search function of our file manager using the user-given name, tags, and metadata(documents edited today, Pages files).

Photos and videos are managed entirely in the photos app, and organised almost exactly according to your suggested categories(literally called memories (for events), places, people). iTunes handles audio files automatically(you can sync your own files into apple music, where they're categorised in the same way as any other music).

As I understand it, APFS also handles copying and modifying in a similar way to your description, where a copy of a file is treated as a mutation of the previous version.

Everything is even synced through iCloud to all your devices, with all macOS devices keeping a rather complete copy, unless they run out of disk space.

This would require someone to have their first experience of computing in the modern Apple ecosystem(literally iOS 11 and up) to avoid preconceptions about filesystems, since traditional folders are still supported, but it's possible.

Re: Choosing between names and identifiers in URLs

#120

Post by kalleboo »

a13n wrote: post #57
jlg23 wrote: post #24

Earlier quoted context omitted.

> For Canny, I wrote some awesome code that I'm proud of that turns a "post title" into a unique URL. Did you mean "slug"? What you are describing is a basic feature of most blogging software since the inception of blogs...

It's way more than that. – Automatically handling duplicates – Avoiding needing to include the unique ID in the URL – Updating the URL after editing the post – Redirecting previous versions to the new version

Wordpress has supported all of that for as long as I can remember
Post reply on HN