Opened 13 years ago

Last modified 9 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:


Links are getting long quick wnen our ID's are mongodb ObjectID's.
` <>`_



    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


    Regular link: [](  
    base58      : [](

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 <>`_.


Change History (9)

comment:1 by Christopher Allan Webber, 13 years ago

Hm. It's an improvement in length by a bit, but not by a huge
amount. I'm not sure that it improves readability or the prettiness
of URLs by much... it's still not a URL you could type in by hand

comment:2 by Christopher Allan Webber, 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:3 by Christopher Allan Webber, 13 years ago

Owner: set to Christopher Webber
Assigning to myself at the request of Joar ;)

comment:4 by Christopher Allan Webber, 13 years ago

Owner: set to Christopher Webber
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
    # To url-safe base64!
    >>> safe_64 = binascii.b2a_base64(ob.binary).strip().replace('+', '-').replace('/', '_')
    >>> safe_64
    # And back :)
    >>> ObjectId(binascii.a2b_base64(safe_64.replace('-', '+').replace('_', '/')))

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

comment:5 by Christopher Allan Webber, 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 Will Kahn-Greene, 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 Elrond, 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 Christopher Allan Webber, 13 years ago

Component: Programming
Status: NewRejected
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.

comment:9 by Will Kahn-Greene, 12 years ago

The original url for this bug was .

Note: See TracTickets for help on using tickets.