Ivek23 asked me to create a plain delphi .psf script for TMDb - so here it is (attachment).
It basically does the same as the other script but should be easier to customize (no need to compile).
Thanks for taking this on. This might be a good way of lightening nostra's burden in keeping things up-to-date. I haven't yet had a chance to test your script thoroughly, but I thought I'd throw out a few comments anyway... [Oops. It ended up kinda long-winded.
]
I'm not sure there's any disadvantages to a script vs. a plugin. They seem to run just as well, and have the advantage of being easily user-modified. That's particularly helpful for things like enabling/disabling specific functions and saving data in custom fields (or even in different standard fields). These modifications are also easy for anyone to do to a well-documented script. It also allows those will a little understanding of the scripting language to do things like modify or format data before it's saved. Although a script doesn't allow runtime options, many 'options' that might be sought can be handled just by using different modifications of the same script. It's arguably easier just to run the script that's modified to do exactly what you want than it is to start a plugin then have to choose an option from a prompt.
The point of this observation is the idea such a script will be most useful to users generally if it gets whatever data is available and offers to save it somewhere—if not an obvious standard field, then an arbitrarily named custom field the user may modify as appropriate and add to their database. The most difficult part for us amateurs is figuring out how to get the data. If that's done, most of us can deal with what to do with it. And some of us will even customize it further to modify and combine the data before saving it—something simply not possible with a plugin. Using this approach also relieves the author of having to respond to inevitable requests to add whatever scrap of data is offered by the source.
I'm not even sure what you've done, so forgive me if the script already includes everything offered by the API (which, I suppose, isn't necessarily everything appearing at the website). But some of my comments apply to the question of what to do with 'people data'. The first consideration here should be that combining this data from that of a different source messes up the integrity of both. The logical choice for most of us is to rely on the IMDb as a primary source for people data. A secondary source should only be used in a 'do not overwrite' mode so it's only used as a secondary source. Even that runs the risk of being run first and thereby fouling the data that should have come from the primary source.
So the best way to handle this is to offer the option of adding the data that 'fits' the standard fields—primarily for those who want to use this as the primary source. And I think what you've done with what's offered by the API is the best you can do. For those already using IMDb as a primary source, the interest is likely in (1) confirmation our IMDb data is good, and (2) capturing any additional data available (e.g., production crew). That can be done by dumping it into one memo field with any role/job function data. The names can be put in links if that information is available. If the data is easily separated (e.g., into cast and crew), it can be put in different fields. If all this can be done, it offers a full range of choices to users: use the script as a primary source, as a secondary source used only where no data is available from the primary source, and/or as a supplementary source where all the data is added to separate fields.
One thing I did notice, but I'm still not sure about, is how it's determining which poster to get. Sometimes it seemed to be the default poster. In other cases, it seemed to be ignoring all posters classified by language (and the default, at least for English movies, is most often 'English') and choosing from those classified a 'other' (often a bad choice). Does the API offer a way to select the default poster, or one classified by the same language as the user language? (I have a simple self-interest in this one. All I want from TMDb is one good poster and it's 'Overview' which I appreciate as a short synopsis.)
Another issue i had is preventing PVD from downloading the webpage URL which i don't care about because i only use the API.
The URL doesn't hurt, and can be used to get to the website, should the need arise. For me, that's usually to see what other posters are available.
