Opened 13 years ago
Last modified 10 years ago
#249 closed defect (WONTFIX)
Base58 any mongo ObjectID's in URLs
Reported by: | joar | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | programming | Keywords: | |
Cc: | Parent Tickets: |
Description
Links are getting long quick wnen our ID's are mongodb ObjectID's. e.g. `http://omgmg.dyndns.org:6543/u/quietjenny/m/4e682b3f4cc6a55e4d0000dd/c/4e692f1f4cc6a55e4d000160/#comment <http://omgmg.dyndns.org:6543/u/quietjenny/m/4e682b3f4cc6a55e4d0000dd/c/4e692f1f4cc6a55e4d000160/#comment>`_ Comparison: :: base 16: 4e682b3f4cc6a55e4d0000dd base 58: 1RlMoQ3FCeZSiuJO and just for perspective... base 10: 24265763280740767849856893149 want more perspective? base 2: 10011 10011 01000 00101 01100 11111 10100 11001 10001 10101 00101 01011 11001 00110 10000 00000 00000 00110 11101 It does not really make a huge difference in size. But it's still some. :: Regular link: [http://omgmg.dyndns.org:6543/u/quietjenny/m/4e682b3f4cc6a55e4d0000dd/c/4e692f1f4cc6a55e4d000160/#comment](http://omgmg.dyndns.org:6543/u/quietjenny/m/4e682b3f4cc6a55e4d0000dd/c/4e692f1f4cc6a55e4d000160/#comment) base58 : [http://omgmg.dyndns.org:6543/u/quietjenny/m/1RlMoQ3FCeZSiuJO/c/1RlbRFH6rhl3jdX36/#comment](http://omgmg.dyndns.org:6543/u/quietjenny/m/1RlMoQ3FCeZSiuJO/c/1RlbRFH6rhl3jdX36/#comment) If anyone has any other suggestions on how to keep the ID's in the URLs as short as possible, `this description of what a mongodb ObjectID consists of might be helpful <http://www.mongodb.org/display/DOCS/Object+IDs>`_. Cheers
Change History (9)
comment:2 by , 13 years ago
One thought is that we can probably maximize slugs a bit in some ways we might not be presently... for example, if no title is given, maybe we can use the filename? I don't remember if we're doing that already. ;) No way to do the same with the comment's id, but linking to comments will be comparatively more rare and pretty URLs will matter a lot less.
comment:4 by , 13 years ago
Owner: | set to |
---|
I guess "marking as myself" wasn't what Joar meant. Regardless, here's a bit of code to convert ObjectIds to/from web-safe base64. :: >>> ob = ObjectId() >>> ob ObjectId('4e6a82bf48b152550b002724') # To url-safe base64! >>> safe_64 = binascii.b2a_base64(ob.binary).strip().replace('+', '-').replace('/', '_') >>> safe_64 'TmqCv0ixUlULACck' # And back :) >>> ObjectId(binascii.a2b_base64(safe_64.replace('-', '+').replace('_', '/'))) ObjectId('4e6a82bf48b152550b002724') I tested it. It's fast, significantly fast. We could go with this route if we wanted to. So the question is... do we want to do this?
comment:5 by , 13 years ago
By the way, that's 24 characters versus 16 characters. 8 characters saved. That's a not-insignificant amount.
comment:6 by , 13 years ago
Chris said the user can create friendly names for the media items and media items are scoped to the user, so that works fine and reduces the /m/ part. So then the issue is the /c/ part. It's currently the mongodb id, but that's kind of silly since comments are scoped to the media. So the key for a comment is (user, media, comment) and that last bit could be an ordinal number which makes the /c/ section really short. It doesn't violate the uniqueness because the complete key is (user, media, comment #).
comment:7 by , 13 years ago
In order of my personal priority 1. I really think, this is a non issue: Comments are linked to rarely, so these URLs may look a bit ugly. 2. willkg is right. There is a proper scope for comments, so comments could have local, scoped numbers. In a proper (distributed) world, this isn't really a problem, as all comments for one media should live on the same server, so generating the next-id should be simple. This gives way nicer URLs anyway! 3. If all this is about shortening the URL? Well, the current comment-id is unique across all comments, so the URL needs to only contain the comment-id, nothing else. Removing the user and the slug. This should shorten the URL enough.
comment:8 by , 13 years ago
Component: | → Programming |
---|---|
Status: | New → Rejected |
So here's what I think. We have a good solution in this ticket in case we ever decide to reverse things, but Will and Elrond have made some compelling points that really we have a solution for media entries themselves, and linking to comments is pretty rare, so no need to complexify things. I actually think that's true enough where we don't even need to complexify the code to add numbered comments (I think with a system like mongo there's some kind of possible race condition there anyway that we should be wary of where some object could exist in one replicated database but not the other in case of a distributed multi-server mongo setup?) So marking this as rejected. If necessary we can always come back to it.
Note:
See TracTickets
for help on using tickets.