2
edits
UDP API DEV: Difference between revisions
Undo revision 16194 by (lol reading bold at the top of the page is hard, I'll submit a tracker item) Fansubcounter (talk)
mNo edit summary |
(Undo revision 16194 by (lol reading bold at the top of the page is hard, I'll submit a tracker item) Fansubcounter (talk)) |
||
| (3 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
{{TOCright}} | {{TOCright}} | ||
'''[[UDP_API_Definition|UDP API]] DEVELOPMENT''' | '''[[UDP_API_Definition|UDP API]] DEVELOPMENT''' | ||
| Line 8: | Line 7: | ||
Feel free to edit / comment / whatever. | Feel free to edit / comment / whatever. | ||
== Data Commands == | == Data Commands == | ||
| Line 39: | Line 37: | ||
=== [[UDP_API_Definition#GROUP:_Retrieve_Group_Data|GROUP]] === | === [[UDP_API_Definition#GROUP:_Retrieve_Group_Data|GROUP]] === | ||
{{missing}} | |||
=== [[UDP_API_Definition#FILE:_Retrieve_File_Data|FILE]] === | === [[UDP_API_Definition#FILE:_Retrieve_File_Data|FILE]] === | ||
*FILE size={int8 size}&ed2k={str ed2khash}[&fcode={int4}&acode={int4}] | *FILE size={int8 size}&ed2k={str ed2khash}[&fcode={int4}&acode={int4}] | ||
| Line 61: | Line 59: | ||
* Retrieve related-episode data with the FILE command, making use of bit 5 (or some other unused bit) of the fcode. Proposed return is a list of episode IDs separated by commas. File 275580 is a fair example of why this is useful; right now there's no way to show that this is a dual-episode file via the UDP API. --[[User:Radicand|Radicand]] 14:32, 27 March 2008 (UTC) | * Retrieve related-episode data with the FILE command, making use of bit 5 (or some other unused bit) of the fcode. Proposed return is a list of episode IDs separated by commas. File 275580 is a fair example of why this is useful; right now there's no way to show that this is a dual-episode file via the UDP API. --[[User:Radicand|Radicand]] 14:32, 27 March 2008 (UTC) | ||
== | == MyList Commands == | ||
=== MYLISTADD: Add file to | === MYLISTADD: Add file to MyList === | ||
Feature request: It'd be useful if the reply of this command would contain the lid of the added file. | Feature request: It'd be useful if the reply of this command would contain the lid of the added file. | ||
| Line 76: | Line 73: | ||
== Notify Commands == | == Notify Commands == | ||
{{missing}} | |||
== Misc Commands == | == Misc Commands == | ||
=== ENCRYPT : Encrypt Command === | === ENCRYPT : Encrypt Command === | ||
This is a major modification of the UDP API encryption scheme which will break compatibility with | This is a major modification of the UDP API encryption scheme which will break compatibility with | ||
older clients. However, the current system has some weaknesses and only few clients support encryption so far. | older clients. However, the current system has some weaknesses and only few clients support encryption so far. | ||
| Line 114: | Line 109: | ||
* prevent the server from unintentionally sending unencrypted data to a client, i.e. notifications. (no more dropping of encryption on decryption failure) | * prevent the server from unintentionally sending unencrypted data to a client, i.e. notifications. (no more dropping of encryption on decryption failure) | ||
=== USERLIST : Retrieve MyList Data of a specified user [{{colour|red|rejected}}] === | |||
=== USERLIST : Retrieve | |||
Feature Request: The purpose is for a client I want to make, which will essentially be a more user friendly method of viewing and manipulating the view of a user's list. Sort by various categories and so on. I would like to be able to view and browse a specified user's list just as I can with the web interface | Feature Request: The purpose is for a client I want to make, which will essentially be a more user friendly method of viewing and manipulating the view of a user's list. Sort by various categories and so on. I would like to be able to view and browse a specified user's list just as I can with the web interface | ||
| Line 160: | Line 154: | ||
:What I'm really interested in is maintaining local dbs of 3/4 user lists and having a client automatically update them every 2/3 weeks. We use this to coordinate information within our country regarding who has what =p. But what we're interested in is a way to be able to selectively retrieve the entire list by some index. Of course if its slow, then it makes sense to maintain it locally and just look for changes. The other thing I really want is to somehow retrieve with MyList file data (or user list file data), the date at which something was added to the list. (I understand this information exists). The idea here is we can locally query these lists for files added within the last 2/3 months. --[[User:path|path]] 11:53, 25 June 2006 (IST) | :What I'm really interested in is maintaining local dbs of 3/4 user lists and having a client automatically update them every 2/3 weeks. We use this to coordinate information within our country regarding who has what =p. But what we're interested in is a way to be able to selectively retrieve the entire list by some index. Of course if its slow, then it makes sense to maintain it locally and just look for changes. The other thing I really want is to somehow retrieve with MyList file data (or user list file data), the date at which something was added to the list. (I understand this information exists). The idea here is we can locally query these lists for files added within the last 2/3 months. --[[User:path|path]] 11:53, 25 June 2006 (IST) | ||
::That's really not wanted usage for this API. Have you thought about the possibility to use MyList export? You know you can make you own export template and get all the info you want at once? A command that query all changes (lids) within the last 2/3 months (or even weeks) is not going to be added. --[[User:Epoximator|Epoximator]] 12:36, 25 June 2006 (UTC) | ::That's really not wanted usage for this API. Have you thought about the possibility to use MyList export? You know you can make you own export template and get all the info you want at once? A command that query all changes (lids) within the last 2/3 months (or even weeks) is not going to be added. --[[User:Epoximator|Epoximator]] 12:36, 25 June 2006 (UTC) | ||
== Other == | == Other == | ||
=== Web Service API === | === Web Service API === | ||
I think most of the UDP API functionality could be exposed as a web service. Not only it would make client programming simpler but could also solve some NAT/Proxy/Firewall UDP problems. This web service would only provide query capabilities, since callbacks (required for notifications) in web services still pose some problems. --[[User:Jassuncao|Jassuncao]] 08:43, 20 September 2006 (UTC) | I think most of the UDP API functionality could be exposed as a web service. Not only it would make client programming simpler but could also solve some NAT/Proxy/Firewall UDP problems. This web service would only provide query capabilities, since callbacks (required for notifications) in web services still pose some problems. --[[User:Jassuncao|Jassuncao]] 08:43, 20 September 2006 (UTC) | ||
| Line 170: | Line 162: | ||
::Since this is not the right place to start a flame war I will not comment. | ::Since this is not the right place to start a flame war I will not comment. | ||
=== HTTP/XML API=== | === HTTP/XML API=== | ||
A complementary [[ | A complementary [[HTTP API Definition|HTTP/XML API]] has been suggested (and approved). See http://forum.anidb.net/viewtopic.php?f=11&t=6871 | ||
[[Category:Development]] | [[Category:Development]] | ||
[[Category:UDP]] | [[Category:UDP]] | ||
[[Category:API]] | [[Category:API]] | ||