Put BitTorrent emulation profiles in files

[sywesk]

All bittorrent clients are hard-coded into RM.cs. I think we should put them in a separate XML or something like that, to be able to dynamically add / remove them without compiling. It would also make the RM.cs more readable.

[apiweb]

I agree, I think it would be better, and become the quickest and easiest upgrade. If you want I can try to implement this functionality. 👍
But before we would have to create a standard for XML, have any suggestions? :-D

[NikolayIT]

I agree with you guys. I personally prefer JSON files.

[silverlays]

I have a suggestion (i don't made it, only taken from Ratio Master 1.9.1)

http://pastebin.com/5x0vcLWp

If it can help...

[apiweb]

I started working on this feature.
I'm using JSON, and for this I installed the Newtonsoft.JSON library.

[apiweb]

I am still in doubt, between using a JSON file for each software. (Ex: A BitComet.json file and all its versions in, another for uTorrent, etc ...) or use a single file for all clients.

For now, I'm using a single Json file, with all the clients inside.
Following this model:
http://www.jsoneditoronline.org/?id=d5aa3d7d5011b8c8091dcdba32fb8b90

[NikolayIT]

All clients in separate files will allow downloading new clients separately.
👍 for separate files.

[sywesk]

@apiweb I see that you took each client profile and put them in separate objects from their client name, and then in each one of them you have the name + versions. Isn't that a bit redundant ? I think you can just put the version as the member name like :

"BitComet": {
    "1.20": {...}
}

Original :

"BitComet":{
    "BitComet 1.20":{...}
}

What do you think ?

Aside from that, the whole file looks good to me :)

---

For the separate files, there's still the granularity to choose : client level, with all their versions, or version level ?

Also, couldn't the JSON be seen as a little database ? thus being updated by the software at runtime with an updater / package manager kind of (and the database could be edited by hand when needed, as it's json). I'm not advocating this approach, just bringing another way of seeing the problem