Connecting pinball resources

@haugstrup: I’ve been thinking about that issue as well, but the alternative to having group ID changes would be not being able to provide any linkable identifiers for the vast majority of games (and there would probably still be some group changes going on anyway).

Considering the two reasons why a group change might occur, I actually don’t think this is a huge issue:

1.) The machine has not been grouped yet: In this case, you’re out of luck anyway, but using the actual IPDB ID for linking purposes might still work. I’m going to add the timestamp of the last group change to each machine, and if it’s 0, you can consider the group ID not final and ignore it, if you want to persist group IDs and not hit up the API every time.

2.) There has been a mistake:

a) I missed a machine that has a lower ID than all the others of its group. Unlikely, but in that case, I’ll keep the established group ID. As for the one I’ve missed, you’re going to have to do an update anyway.

b) Some established group membership turns out to be wrong, e.g. we bunch together GoT and GoT LE, and upon seeing tournament footage we realize that’s not right. There’s nothing that can be done about that, the group ID has to be updated.

c) I dun goofed. If there’s any stupid mistake on my part, the group IDs will have to be updated no matter what.

To mitigate the impact of group changes for people not wanting to hit up the API every time, the timestamps I mentioned might help, but I could also see a subscription model working – I’ll keep the API URLs of applications wanting to get notified of group changes and tell them every time a change occurs, so there won’t be any limbo links until their cache expires. I think, all in all, this would work better than never changing group IDs, which I’m afraid I can’t guarantee anyway.

@romballs: We had a bit of a collision there, I answered by email just as you replied here. My reply may have been a bit wordy – @haugstrup said it just as well, and way more succinctly.

Well, you know, cache invalidation and naming things …

You’re right, there should probably be a better name for that, but I’m not sure about UPID – I mean, like, what’s a “pinball”? For collectors, the distinctions the IPDB makes are probably pretty important, so that UPID would definitely not be unique to them. It’s a sort of players’ UPID. I’ll take suggestions.

For anyone wanting to persist the group data requested from the API on their end, I added some stuff to make this more feasible:

1.)

Each request now also gives you the timestamp of the last time anything changed with the IPDB entry’s group.

This could mean that the entry has been assigned to another group, or that it stayed in its default group, but it has been made “official”, or that some other machine has moved into or out of the group it belongs to.

If the timestamp is 0, this means that there has not been a manual group assignment yet (in this case the default group ID will always equal the IPDB ID). You can still use such group IDs for linking purposes, but it might not work if the resource you are linking to chose a different IPDB ID than you did for that machine. It’s probably reasonable not to persist those 0-timestamp responses, unless you are using the stuff outlined in points 2 and 3.

2.)

If you do want to persist group IDs on your end, you have to do periodical updates, so your links won’t become stale. I can’t guarantee that assigned group IDs will never change.

You can hit e.g. http://pinballvideos.com/api/ipdb_group_updates/1442162000, which will give you data on all the changes that have occured since your last update (meaning since the timestamp you’re sending in the last URL segment).

The response is an array of updated objects in the same format requests to /api/ipdb_group/[IPDBID] will produce. What “updated” means is described in point 1.

3.)

To make sure your persisted group data is always up to date, you can give me an URL that I will hit whenever there has been an update. When you get that ping, you can update your stuff as described in point 2.

TL;DR:

If you want to check the API whenever you get an incoming request or need to generate a link, that’s totally fine, but if you want to store that data on your end, there’s stuff you can use to make sure that nothing breaks when I’m updating groups.

Does anyone know who handles IPDB from the tech side? It would be cool to get this ‘group’ concept built into their data.

2 Likes

Looks like it’s a fellow named Christopher Wolf. I’m emailing him now :slight_smile:

1 Like

From my experience, there’s a delay between when a machine is released and when it’s added to IPDB. For example, Full Throttle is on location right now, but it’s not yet on IPDB.

So, there will be a period when we won’t be able to connect to one another via IPDB ID.

1 Like

There are three things that suggest that this might not be that much of a problem:

1.) It’s mentioned in several places on ipdb.org that if there’s a machine missing, you can just contact them, and they’ll add it.
2.) There are lots of machine stubs without any detailed information or images, so I suppose getting a game added just to give it an IPDB ID shouldn’t be a problem.
3.) The change log says that there are hundreds of updates each month, so this should probably go pretty fast, too.

I haven’t talked to whoever runs IPDB, but it seems getting something added is fast and easy.

I’m not sure it’s that great a fit. The IPDB has this encyclopedia vibe with hard facts all around, and what constitutes “basically the same game to actual pinball players” is very much up to interpretation.

I feel this sort of thing is more at home at a players’ type of resource. That said, if it does get integrated into IPDB, all the better. I’m not sure if they are even providing an API there right now, though.

Sadly, they have taken the opposite approach: The Internet Pinball Database FAQ

1 Like

Good point. I’ve only taken a passive approach with IPDB. I’ve never contacted them, but instead always just wait until the pin is added (in my experience the delay is usually a couple of weeks after release).

Well then. I’d still be curious to know if they reply to you.

1 Like

I’ve read that, but to me it sounded like it’s more of a bandwidth issue, with people scraping the whole thing and embedding remote images. Not sure, though, might also just be a reasonable excuse for just not wanting to make their data available (which is fine, too, of course).

Anyway, if you hear back, let us know.

When I previously contacted IPDB to inquire about API access (I wanted to integrate support into my League Manager system, to more easily do things like machine name autofill) Christopher Wolf sent a rather brusque reply to the effect that there was no API, there would be no API, and that they considered their data to be copyrighted. Yikes.

1 Like

Well, that’s a disappointing stance. Especially considering that facts collected in a database are not protected by copyright (e.g. the production year and designers names etc). I guess I shouldn’t hold out hope for an answer and if we want interoperability between pinball software it might be best to build something open and free (and in beer and speech) ourselves not based on IPDB. It can only cause problems going forward if IPDB is not willing to work with anyone else.

1 Like

That is a disappointing stance considering the public donates all of the information to it. Guess it’s time to start a new ipdb with specific content licensing and actual hi-res pictures (personally, so over all the 640x480 stuff). Who’s starting OPDB (open)?

5 Likes

The more I think about this the more annoyed I get. I’ve taken the first step and registered OPDB.org

9 Likes

I’d be glad to contribute coding time and general slave labor :slight_smile: to such a project.

1 Like

Awesome, I’ll make a github project momentarily #annoyed

1 Like

https://github.com/haugstrup/opdb/issues

4 Likes

Sweet. I’m busy for the next few hours, but I’ll offer some commentary soon.

2 Likes

Cool, let’s see how this works out. In the meantime, I will of course continue to keep the thing I’ve set up updated.

1 Like