> 3. We could introduce new setting, which store the values in bytes. For example, download-limit-bytes could replace download-limit.
This is a pretty good idea.
> 4. I don't get this point. RPC/JSON? third-party apps? A little more explanation is required.
There are a lot of third-party applications that can act as "remote controls" for Transmission... there's a Web GUI, two Windows GUIs, a Java GUI, ones for iPhones and Android phones, and on, and on. The important part here is that we need to not change the JSON-formatted RPC API they use to talk to Transmission.
> 5. Instead of changing tr_sessionSetSpeedLimit(), a new function should be introduces to change the speed in bytes (for example tr_sessionSetSpeedLimitBytes). The old functions will then still work.
This is a good idea. I don't see any downside to this. :)
> 3. We could introduce new setting, which store the values in bytes. For example, download- limit-bytes could replace download-limit.
This is a pretty good idea.
> 4. I don't get this point. RPC/JSON? third-party apps? A little more explanation is required.
There are a lot of third-party applications that can act as "remote controls" for Transmission... there's a Web GUI, two Windows GUIs, a Java GUI, ones for iPhones and Android phones, and on, and on. The important part here is that we need to not change the JSON-formatted RPC API they use to talk to Transmission.
> 5. Instead of changing tr_sessionSetSp eedLimit( ), a new function should be introduces to change the speed in bytes (for example tr_sessionSetSp eedLimitBytes) . The old functions will then still work.
This is a good idea. I don't see any downside to this. :)