Plea for streamlining uploadsubtitles and tryuploadsubtitles

[eduo]

I know we've talked about this in the past, but I've been checking it and I think I have found how to minimally modify the current methods to allow more flexibility and less waste.

As you know, currently both TryUploadSubtitles and UploadSubtitles are really made to upload single movies (1 or several subtitles, but all technically multiple CDs for the same movie/tv season).

Also, one of the holes for the current API is that it doesn't allow users to "get late in the game" because it punishes users who try to upload a lot of things by dealing with each movie as a single transaction and a single response.

The problem with modifying the API is that older clients could break. Especially since we're not using any sort of versioning to allow specific functionality to go in (so, for example, clients might've been broken with the recent addition of SubtitleLink and AnonymousTo, whatever the last one means).

I've checked TryUploadSubtitles and the Query could contain a struct for each movie, as it currently has for a single one. The response would need to have a single additional value (subhash) and then loop through all responses.

For UploadSubtitles it's even easier, as it's just a matter of adding arrays as the current one and looping the response integrating the subhash in the session-id of php like an anchor tag. ( #3343343 ), which doesn't affect the URL nor the structure.

I say this because I've noticed it takes forever to check for dozens of subtitles, none of which may be present, because the query needs to be done one by one (unless I decide to thread and send 10 simultaneously, but that seems overkill).

Also, while XMLRPC is dandy and everything, have you considered using a less "chatty" interface? Something that is more efficient and wastes less bandwidth? JSON for example (I'm not a big fan of JSON over XML, but it's a lot less wasteful).

If not this then maybe some of the methods can be changed to receive serialized values instead of pure XML optionally

Original:

Code: Select all

<struct> <member> <name>cd1</name> <value> <struct> <member> <name>subhash</name> <value> <string>7fc75defd9e66325ff34b72fece1e68a</string> </value> </member> <member> <name>subfilename</name> <value> <string>Big%20Bang%20Theory%201x01%20-%20Pilot.en.srt</string> </value> </member> <member> <name>moviehash</name> <value> <string>f6638dd763d29d38</string> </value> </member> <member> <name>moviebytesize</name> <value> <double>244445184</double> </value> </member> <member> <name>moviefilename</name> <value> <string>Big%20Bang%20Theory%201x01%20-%20Pilot.avi</string> </value> </member> </struct> </value> </member> </struct>

Serialized (single line):

Code: Select all

"cd1","7fc75defd9e66325ff34b72fece1e68a", "Big%20Bang%20Theory%201x01%20-%20Pilot.en.srt", "f6638dd763d29d38","244445184", "Big%20Bang%20Theory%201x01%20-%20Pilot.avi"

This is the very exact same XML structure, down to just the data. If you want you can even throw it into a mapper and it should map into the method's template right away and have it processed by the XMLRPC handler anyway in memory.

Of course, the most efficient way to handle this would be to open a port and have an interactive communication, but that may be overkill on the servers.