340
edits
Talk:OstDB DEV Foosic: Difference between revisions
no edit summary
Epoximator (talk | contribs) m (→Protocol) |
No edit summary |
||
| Line 12: | Line 12: | ||
::: i don't see why it should be public. we already have a public interface and that is the UDP API. (the MATCH command doesn't make any sense for external use atm because of the ofid argument, btw). it shouldn't make much difference @ performance either. and the clients would still have to communicate with the udp api to get any useful info. adding a new public service will just lead to more confusion and expose a service that's main function is only for internal usage --[[User:Epoximator|Epoximator]] 06:49, 22 May 2007 (UTC) | ::: i don't see why it should be public. we already have a public interface and that is the UDP API. (the MATCH command doesn't make any sense for external use atm because of the ofid argument, btw). it shouldn't make much difference @ performance either. and the clients would still have to communicate with the udp api to get any useful info. adding a new public service will just lead to more confusion and expose a service that's main function is only for internal usage --[[User:Epoximator|Epoximator]] 06:49, 22 May 2007 (UTC) | ||
:::: if we don't make it available as a public service the UDP API would have to take it's place. Some usage scenarios will require a way for clients to find out potential ofids for a file by fingerprint. I.e. a music player plugin which retrieves file metadata (ID3 tags) from anidb (like the musicbrainz plugins do) would first try to identify a file by content hash via the UDP API. But if that fails it would try to get a potential match via the foosic fingerprint. | |||
:::: though you're probably right. It would be a lot simpler for client developers if they could simply send a single lookup query with size, content hash and fingerprint to the UDP API and get either a definitve or a potential match as result instead of having to contact multiple APIs. | |||
:::: that would mean that the UDP API would need to do internal lookups via the matching redirector for lookup queries where the content hash is unknown and delay it's reply to the requesting client until it got the matching data from the redirector. seems feasible. | |||
:::: [[User:Exp|Exp]] 07:25, 22 May 2007 (UTC) | |||
=== OLD Stuff === | === OLD Stuff === | ||