[topfs2]

I'd like to state that I have no problem with the path in core (which as you saw on your ticket I liked), its mainly that I don't see the need for a client to send the path, for many reasons.

And yeah jsonrpc wouldn't technically need to check the path but since its exposing the core method I either need to have jsonrpc do a check, or be garantued that the underlying does it, which I dislike assuming.

So if you want #1 what you really are after is a AddPathToLibrary or AddMediaSource with the possibility to add autoscan. This is a method I think would make sense having as I see more uses in this, for example web gui could allow user to add sources etc. If you still wish to make #2 I would suggest making it to instead of taking a path, take a media source. And by media source I mean an ID which is given in the GetMediaSources method (IIRC the name correct). That way it would perhaps be same security as a full scan, still can't say I perticularily approve of it but that way you have more of a chance for inclusion (perhaps other developers will vote in your favour).

At any rate, when I began this discussion all I wanted was to point out that I think there is a much better way solving the problem, since you run NFS and is tech savvy it may not be perfect but for the vast majority of users a polling solution over NFS is what they would expect, not a script on server telling xbmc what to do.

[xgamer99]

Thank you for you opinions. It makes a bit more sense to me now and gives me a few more options if I wish to pursue this.

I'd like to state that I have no problem with the path in core (which as you saw on your ticket I liked)

Yeah, that kinda left me confused. So, you're not against having path parameters in core, but you're against having JSON pass those along. And as I understand it, that's because other core XBMC functions are calling to them properly with proper paths and security built-in, but when you give that privilege to JSON it overrides much of the built-in checks and executes it directly? If that's the case, then I think I can understand the problem now.

I can see what you mean by this is a bigger problem than I initially thought. I'll continue looking at it and hopefully figure out a way to do this efficiently and securely. If anything, this gives me a bit more experience with the language and workings of XBMC, which is only a good thing.

[topfs2]

Yeah, that kinda left me confused. So, you're not against having path parameters in core, but you're against having JSON pass those along. And as I understand it, that's because other core XBMC functions are calling to them properly with proper paths and security built-in, but when you give that privilege to JSON it overrides much of the built-in checks and executes it directly? If that's the case, then I think I can understand the problem now.

Yeah while the internal method will check if the path is correct and existing I don't like the idea of allowing a client to state which path. While there is a security issue (which in this case is handled already since we assume #2) the biggest problem is that its hard to cover all cases. Like how to format the url properly so its what we store internally.
As an example /media/tvseries/ might have changed but internally we might map this as special://uuid/abs48ds4x57q75x/ when you add it via gui (we don't but there are other feature requests pending that would force us to do). I realise that NFS is not in this perticular case since it will have only one form of URL but the point is that if a method is added it should cover ALL possible cases nicely. Also looking at other feature requests it might be true that NFS would be stored as special://mediasource/X/nfs://192.168.0.2/shows. If sending an ID (which xbmc have given and in NFS case would be X) then it makes more sense, that way you are only scheduleing a pre-mature scan of something we have already planned on scanning. While its probably possible to derive nfs://192.168.0.2/shows from the nfs example, its not magic and code must support this.

So this is why I'd rather see core handle it themself, since A) its more sturdy B) it will benefit more users and would benefit them magically.

[takoi]

If you're just modifying my script xgamer99, to use http calls instead, just know that giving the path wont work as is. Lets say xbmc is already running an update, and you start creating/moving other files around. How would you handle this? If you want to specify the path then you have to make a call for each. In my case (since im scanning the whole library) i only need to do it once.