RatioMaster.NET icon indicating copy to clipboard operation
RatioMaster.NET copied to clipboard

Put BitTorrent emulation profiles in files

Open sywesk opened this issue 11 years ago • 7 comments

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.

sywesk avatar Feb 08 '14 21:02 sywesk

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. :+1: But before we would have to create a standard for XML, have any suggestions? :-D

apiweb avatar Feb 12 '14 16:02 apiweb

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

NikolayIT avatar Jan 07 '16 21:01 NikolayIT

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...

silverlays avatar Feb 25 '16 02:02 silverlays

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

apiweb avatar Dec 24 '16 15:12 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

apiweb avatar Dec 24 '16 16:12 apiweb

All clients in separate files will allow downloading new clients separately. :+1: for separate files.

NikolayIT avatar Dec 24 '16 18:12 NikolayIT

@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

sywesk avatar Feb 21 '17 12:02 sywesk