Any comments or suggestions on the protocol as described in XmlRpc should be added here.
- Security: authentication possibly should use the
WWW-Authenticate:
headers on HTTP, rather than as parameters to the URL.- you're right, but still this doesn't prevent sniffing ? The perfect response would of course be a challenge response auth. But we have to keep in mind that irate isn't a critical service :) so there's no real need in my mind to add too much overhead. Let's use HTTP auth !
- HTTP auth won't prevent sniffing, but it also won't be logged in proxy servers, so basically is less likely to be accidentally caught. Robin
- Naming: link should perhaps be renamed to url in keeping with the fact it isn't really a link, but is a URL.
- is an ed2k hash an "url" ? or "uri" ? urn ? i don't really know the difference. Does someone ?
- there is a difference between url, uri, and so on. Damned if I know what it really is however. Robin
- A function should be added to request a specific track by ID, to allow for using multiple clients sharing an account. That way, if a client does irate.getRatings, it can fetch any tracks that are returned that it doesn't know about.
- That was the purpose of the undocumented (oops) function irate.getInfo, added now in the wiki :)
- It's not there currently, maybe you didn't add it right? Robin
- yup, you were faster than me :) added now.
- Error codes: a list of error codes should be defined so that clients can respond sensibly to errors. --Robin
- Yes !! Implementing them as soon as I can.
- Cool. I suggest we start at 800 (the recommended start point for PHP's XMP-RPC library) and go up from there. Robin
- irate.rate: why rating AND weight? What's wrong with just rating?
- I implemented weight as a future extension. Actually I'm already using of it on www.jamendo.com : users can rate albums on this website. But they can also add songs to their playlist online. And they'll be able to rate songs with irate-client. But when they rate an album, they irate all the tracks of this album with weight=0.2 (maybe there are tracks in the album they didn't like...) ; when they add to playlist, they irate with weight=0.5 (we can be more sure that they like the track) ; and when using irate-client, weight will be =1. So in the recommendation algorithm, insted of counting the ratings, you'll sum the weights. (a track rated 6/10 with weight=0.2 by 5 users will "equal" another one rated 6/10 with weight=1 by 1 user.) This is also in my mind the way to implement "listening times", eg. if the client rated the track 5/10 after listening only to the first minute, don't give this rating a full weight. What is your opinion on this ?
- iRATE uses the rating as both the 'how much I like this' and as the 'how often I want to hear this' measure. From the POV of the client, I think that it is unnecessary to split them up. It just adds (imho) unnecessary complexity to the client. Robin
- well this depends on the client. The weight defaults at 1, so if the client doesn't want to use weights, it can just ignore the weight param in irate.rate
- Why do you have -0 and -1 after the IDs? Is -0 to indicate a LibreDB? and -1 a local ID thingamee? Also, why the weird format for local IDs of: XXXXXXX-YYY-ZZ-1? Why the extra dashes?
- Yes -0 is for libredb tracks and -1 for local tracks. I kept the same structure for local tracks and libredb tracks. That is, XXXXX is an incremented value, YYY is for the media (001 for audio, we'll see later if we launch irate video :) and ZZ for a modulo 97 checksum. I'll strip the dashes, they have no interest. It was only to look like ISBN numbers.
- OK, an ID is obviously a good thing. I don't know about the need for splitting them into categories by type, but again it doesn't really matter and may prove useful. The checksum thing shouldn't be necessary, as I don't see a situation where people are typing in IDs. If they are, either the ID exists or it doesn't, so it shouldn't matter there either. Robin
- libredb IDs needed to be redundant, that's the reason of the checksum. I don't think it adds too much overhead.
Page last modified on January 17, 2005, at 01:46 AM