Nargery: lists of identifiers

[marnanel]

If you're not interested in coding nargery, you can skip this post.

Two things you need to know to read it:

1. It's a lot simpler to pass lists of strings over DBus than it is to pass lists of pairs of strings.
2. Images on imgur.com are identified by a five-character code, such as c7bC9. This gives us a URL of http://i.imgur.com/c7bC9.jpg , but you can also find a thumbnail by appending an "s" to the basename: http://i.imgur.com/c7bC9s.jpg .

I have a call in the DBus service that forms the back end of the imgur integration: it lists all the images you have uploaded. Now, a thumbnail of each such image is held on disk with the same basename as the image's ID. So here, "/home/marnanel/.local/share/imgur/c7bC9.jpg" (note: not c7bC9s.jpg, even though it's the same file as the URL which ends that way).

Clients might want to know two things about each image: its ID, and where to find a thumbnail. We could just list IDs, but then the client would have to make a call for every ID, asking where the thumbnail was, and that would be wasteful. I could have passed pairs of strings, but that's a bit clunky. What I did instead was to say that a filename was considered a non-canonical form of ID. When you pass in a filename, it takes the basename and uses that as an ID instead. So we can just supply a list of filenames of thumbnails, and the client can use those filenames as IDs, and we still know what they mean. It works rather well.

Now I would like to extend this by allowing people to look up not only images they have stored locally, but also the popular images of the day. Clearly the filename trick could be extended to URLs. But as mentioned earlier, http://i.imgur.com/c7bC9.jpg is the address of the original image, not the thumbnail. So we have a choice between sending them a list of full-size images, and sending them thumbnails and having to rewrite the canonicalisation rules.

I could

• say that six-character IDs ending in "s" are a non-canonical form of five-character IDs with the "s" removed. I am leaning towards this option. It keeps everything in line, but it's a bit of a hack, and after all we're receiving the actual thumbnail URL. On the other hand, we could always check that the actual thumbnail URL is what we expect, and discard the entry if it isn't.
• supply five-character IDs, but expect the client to know how to turn the URL of an image into the URL of a thumbnail. This is also a bit of a hack, because it's specific to imgur.com and I expect it might be useful to run this program against other servers.
• just give up on this thing and supply pairs of strings instead.

Your thoughts, gentle reader, are as welcome as ever they were.

Comments

[(Anonymous)]

A map from string to string, a{ss}, ID => thumbnail?

(Which is essentially the same as a list of pairs, a(ss) at the libdbus level, but high-level bindings traditionally map it to a dict or GHashTable or whatever, making it less annoying to deal with.)

Semi-relatedly, Unix filenames aren't strictly guaranteed to be UTF-8, and D-Bus strings must always be UTF-8; consider using a map from string to byte-array, a{say}, or an a{ss} where the values are file:/// URLs (which can be %-escaped). If you use byte-arrays, including the trailing '\0' is recommended, so g_variant_get_bytestring() will be nice to you.

--smcv, whose openid dreamwidth seems to be unhappy with

[marnanel]

Your idea is a good one. The only reason I'm a little bothered about it is that ordering is somewhat important in the case of local thumbnails (the list is returned with the newest ones first), and using an a{ss} would presumably destroy the ordering. But I could always have the "recent files" thing remaining as as and the "remote files" thing returning an a{ss}. Or perhaps I should just bite the bullet and use a(ss) for everything.

Also, good point about UTF-8! I should be using file:/// URLs anyway.

mGdwCuDhzgKXT

[(Anonymous)]

IzBvFN Hello! How do you feel about young composers?!...