Jump to content

[REQUEST] bt.prio_first_last_piece would be nice


alessio.71

Recommended Posts

It is possible to change this setting through the HTTP API directly

Are you sure? Based on the frontend code, if bt.prio_first_last_piece isn't visible, then it wasn't sent with action=getsettings. That is, bt.prio_first_last_piece is in the HTML/JS, but only gets unhidden if it is sent by the backend. As I understand it, action=getsettings also sends some access permissions now in the v3.0 WebUI backend, so if it doesn't even send bt.prio_first_last_piece in that list, I seriously doubt it's settable by action=setsetting. I know µTorrent v3.0 isn't µTorrent Server v3.0, but attempting to apply action=setsetting on bt.prio_first_last_piece results in "invalid request" in µTorrent v3.0.

Honestly, this raises a larger question/complaint that I've had with the v3.0 backend, where settings seem to be arbitrarily hidden (or, I guess, are arbitrarily unexposed). Even settings that were previously exposed in earlier versions of the backend, and had no adverse effects from being remotely configurable, are missing now in v3.0.

I think it would be prudent to expand/generalize this request to pretty much be "Re-evaluate all user-facing settings, and determine which ones should not be exposed via the WebUI backend". Because really, most settings shouldn't be hidden if WebUI is to be as flexible as possible. And IMHO, the only reason a setting should be unexposed is if it poses a clear security/stability/reliability risk to users. If a new user-facing setting is ever added in µTorrent in the future, it should be evaluated to determine whether or not to hide it from the WebUI backend. This pretty much goes for all platforms -- not just the Linux version.

Aside: While we're discussing what should/shouldn't be exposed for WebUI, it should be noted several requests are also locked to certain versions of WebUI. For example, action=getversion works only with the Server, and action=getpeers only works with Falcon enabled. This is rather odd, because there's no reason for such limitations on these requests (there are probably more such reuests that I haven't listed off the top of my head). Given that, I guess what I'm driving at is: The API should be made uniform across platforms too.

Link to comment
Share on other sites

It is possible to change this setting through the HTTP API directly

Are you sure?

I just looked at the code in the branch from which uTorrent Server is built' date=' and the setting's HTTP access is read-write for the server product.

Based on the frontend code, if bt.prio_first_last_piece isn't visible, then it wasn't sent with action=getsettings. That is, bt.prio_first_last_piece is in the HTML/JS, but only gets unhidden if it is sent by the backend.

Yes. It doesn't make much sense to present a web interface for a setting for which the server/client doesn't provide access. I suppose it could be useful to show an "unavailable" note for certain settings that are available in other products, but it could also be clutter (for example, the entire directory tab is disabled for the embedded product, so showing a bunch of unavailable attributes could be confusing).

Also, the front end code for v3.0 differs from the front end code for the server and embedded products.

As I understand it, action=getsettings also sends some access permissions now in the v3.0 WebUI backend, so if it doesn't even send bt.prio_first_last_piece in that list, I seriously doubt it's settable by action=setsetting. I know µTorrent v3.0 isn't µTorrent Server v3.0, but attempting to apply action=setsetting on bt.prio_first_last_piece results in "invalid request" in µTorrent v3.0.

Looking at the trunk code (from which uTorrent v3.0 is built), that setting isn't exposed through the HTTP interface, so I would expect you to get the result you saw.

Honestly, this raises a larger question/complaint that I've had with the v3.0 backend, where settings seem to be arbitrarily hidden (or, I guess, are arbitrarily unexposed). Even settings that were previously exposed in earlier versions of the backend, and had no adverse effects from being remotely configurable, are missing now in v3.0.

I think it would be prudent to expand/generalize this request to pretty much be "Re-evaluate all user-facing settings, and determine which ones should not be exposed via the WebUI backend". Because really, most settings shouldn't be hidden if WebUI is to be as flexible as possible. And IMHO, the only reason a setting should be unexposed is if it poses a clear security/stability/reliability risk to users. If a new user-facing setting is ever added in µTorrent in the future, it should be evaluated to determine whether or not to hide it from the WebUI backend. This pretty much goes for all platforms -- not just the Linux version.

Many settings are available via the HTTP interface. Some settings are read-only on some products, and some are completely unavailable on some products. One setting is write-only (password) since typically people don't want to present the current value of the password, but just need to be able to update it.

The product that probably has the greatest number of restrictions on settings is the embedded product; that's because it is installed in what is in effect an appliance - a black box which the manufacturer has set up - and changing some of those values doesn't make sense and can cause trouble if the user doesn't have full knowledge of and control over the internal setup of the appliance.

I added an item to our issue tracking system about this issue. Specifically for this setting, it seems that the server branch and trunk should provide the same access.

Aside: While we're discussing what should/shouldn't be exposed for WebUI, it should be noted several requests are also locked to certain versions of WebUI. For example, action=getversion works only with the Server, and action=getpeers only works with Falcon enabled. This is rather odd, because there's no reason for such limitations on these requests (there are probably more such reuests that I haven't listed off the top of my head). Given that, I guess what I'm driving at is: The API should be made uniform across platforms too.

Earlier, I added an item in our issue tracking system for exposing action=getversion on all platforms. I just now added an item for exposing action=getpeers, although this should get resolved once I start building the server on a newer branch, which should be soon, given the so-far-so-good results of a stress test on the newer branch.

However, there will probably continue to be some differences in the API among products. For example, the save-in attribute of an RSS request shouldn't be exposed on the embedded product because the typical user won't know the internal structure of the file system on an appliance. Also, the bringfront action isn't appropriate on anything but the GUI client. Also, the takeupdate action isn't appropriate on an embedded system since the manufacturer would need to update the firmware.

Link to comment
Share on other sites

@mcdonald:

Yep, I totally get and expect there to be some platform-specific actions/requests/settings, where it doesn't make sense to make it uniformly available across all platforms. What I was referring to was the bits that are shared/shareable should be made so always, as a policy. Not just from an external functionality standpoint, but really, I would expect it to be easier to manage your own code if you make the API as uniform as possible anyway. Then again, I don't know the dependencies and stuff going on in the backend, so it's probably likely I'm just talking out of my arse :P

And yeah, I know the frontend code for the server has differences from the frontend code I normally deal with, but I was looking at the server distribution of webui.zip for reference when I posted above.

The general overview of what I'm getting at is that whatever could be/would be/is stored in settings.dat (or whatever the platform-equivalent is) should by default also be sent with action=getsettings. Exceptions, of course, have to be made (like passwords as mentioned, among other things). But as I was telling Firon yesterday, the restrictions should (IMHO) be done on a blacklist basis, so to make the backend more scalable and flexible for the frontend. My assumption is that there shouldn't really be that many settings.dat settings that require special permissions -- probably not enough to warrant whitelisting anyway (or is the embedded version really that restricted?).

Admittedly, I have a very narrow perspective though, since I can't/don't know enough about how the other distributions of the µTorrent core are handled. But it's just something that's been on my mind, because I've noticed that a lot of settings that worked fine in older versions are getting needlessly restricted in the newer backends.

Link to comment
Share on other sites

@mcdonald:

whatever could be/would be/is stored in settings.dat should by default also be sent with action=getsettings. ... the restrictions should (IMHO) be done on a blacklist basis, so to make the backend more scalable and flexible for the frontend. My assumption is that there shouldn't really be that many settings.dat settings that require special permissions -- probably not enough to warrant whitelisting anyway (or is the embedded version really that restricted?).

I've noticed that a lot of settings that worked fine in older versions are getting needlessly restricted in the newer backends.

We did go to a default-deny from a default-accept declaration system for settings because it made the code simpler when dealing with multiple products. The consequence of this is that settings are not exposed unless the developer explicitly sets that up.

I encourage you to list the settings you think are needlessly restricted (and for what product, since there are differences among products).

There are some new settings that are truly read-only. It seemed to be more overhead than it was worth to make a separate action to obtain these values, so it seemed better to include them with the settings and give them read-only access.

One example of a set of new read-only settings is upnp.external_tcp_port, upnp.external_udp_port, and upnp.external_ip. The user can't specify these because they are chosen by the UPnP router. These are going to be presented in the web UI at some point (maybe in the About box), because some people (including embedded customers) find it useful to have this information.

One example of a new action is in retrieving transfer cap data, where the dimensionality of the result and the timing of the retrieval made it more awkward and less efficient to force into a setting.

Link to comment
Share on other sites

Er, in my rush to post before leaving the house, I ended up writing "a lot" when I meant "several". This is a list of things I've observed to be missing, between µTorrent 2.0 and µTorrent 3.0 (both on Windows, since I am unable to test the releases for other platforms):

bt.enable_tracker

bt.multiscrape

bt.prio_first_last_piece (discussed above)

bt.scrape_stopped

bt.send_have_to_seed

bt.set_sockbuf (questionable need, but nevertheless, missing in 3.0)

dht

gui.dblclick_dl

gui.dblclick_seed

pex

At one point in the past, even the ever-important webui.cookie was disabled until I kept bothering Firon about it... for several months. Luckily, it wasn't a stable release, but if something as simple and critical as that took a few months to be fixed... (Yeah, it was just a regression that probably happened in the transition from blacklist to whitelist, but still :P)

This kind of thing where we have to remind developers to expose a setting is something that I'm actually fearing, because of the sometimes (or often?) slow turnaround for getting it done. Basically, in the event that a setting for a new functionality isn't exposed when build X gets released, then backend API consumers end up getting constrained until build X+y (where y can be arbitrarily large -- or small, on a good day). If it happens on a stable build, the timescale until the next stable build is released with the relevant setting exposed will probably measure in weeks to months again.

Anyhow, maybe I'm just being pessimistic. I'm definitely making a big deal over something that's essentially just a minor detail -- that's for sure. If nothing else becomes of my rambling here, though, then at the very least I'm hoping it makes this "don't forget" mindset more salient in developers' minds.

Link to comment
Share on other sites

This is a list of things I've observed to be missing, between µTorrent 2.0 and µTorrent 3.0 (both on Windows, since I am unable to test the releases for other platforms):

Thanks - I did some research in the source code.

bt.enable_tracker

bt.multiscrape

bt.prio_first_last_piece (discussed above)

bt.scrape_stopped

bt.send_have_to_seed

bt.set_sockbuf (questionable need, but nevertheless, missing in 3.0)

These are disabled in 3.0 and disabled on the server. I'll ask around about these.

dht

I found this to be enabled in trunk (3.0) and the branch from which the server is currently being built.

gui.dblclick_dl

gui.dblclick_seed

These two are disabled in both trunk (3.0) and the server's current branch. I think this is OK. While there would possibly be an interest in controlling how the GUI responds via the HTTP interface, I'm having difficulty seeing why.

Although, if you want to control how the web UI responds to a double click so that by default it matches the GUI, and can be overridden (through a value stored in webui.cookie), I'd consider changing these to being read-only through the HTTP interface (of the GUI client, not the embedded product or server product). Let me know what you think.

pex

I found this to be enabled in trunk (3.0) and the branch from which the server is currently being built.

At one point in the past, even the ever-important webui.cookie was disabled until I kept bothering Firon about it... for several months. Luckily, it wasn't a stable release, but if something as simple and critical as that took a few months to be fixed... (Yeah, it was just a regression that probably happened in the transition from blacklist to whitelist, but still :P)

This actually was intentional originally (I've forgotten the details), but restored later as you know.

This kind of thing where we have to remind developers to expose a setting is something that I'm actually fearing, because of the sometimes (or often?) slow turnaround for getting it done. Basically, in the event that a setting for a new functionality isn't exposed when build X gets released, then backend API consumers end up getting constrained until build X+y (where y can be arbitrarily large -- or small, on a good day). If it happens on a stable build, the timescale until the next stable build is released with the relevant setting exposed will probably measure in weeks to months again.

Fortunately, the one long delay was intentional and not an oversight. Not very helpful to not have webui.cookie for awhile though.

Anyhow, maybe I'm just being pessimistic. I'm definitely making a big deal over something that's essentially just a minor detail -- that's for sure. If nothing else becomes of my rambling here, though, then at the very least I'm hoping it makes this "don't forget" mindset more salient in developers' minds.

Your comments are being considered. Notifications that you are missing formerly-available features are welcome. I expect to resolve the issues sooner than was the case for webui.cookie.

Link to comment
Share on other sites

"dht" and "pex" were definitely missing from action=getsettings. I checked again with µTorrent v3.0 build 22091 22145 to make sure, and they're still not there.

Indeed, I'd originally considered just storing those those gui.dblclick_* options in webui.cookie instead, but my point in using whatever µTorrent itself uses was to

  1. provide closer integration with the desktop UI where possible and where it makes sense
  2. minimize duplication of settings stored in settings.dat
  3. minimize reliance on webui.cookie where possible (this one is of lower priority, but still is something I'd prefer to happen because I don't feel like anyone really should be relying on something like webui.cookie -- it's just a necessity in some cases)

To shadow the settings in webui.cookie detracts from these goals.

I guess this type of integration might be slightly "bad" from a UI code shareability standpoint, since not all ports of the core will share these specific UI settings (so trying to use these settings may make it harder to use the same frontend code with different backends). But that's easily worked around by storing the settings in webui.cookie if and only if the setting isn't found in action=getsettings to begin with. It won't quite be using webui.cookie to shadow those settings, so at worst, it'll offend (3) as listed above.

Basically, I think I'd still prefer it if the setting were given with read/write access rather than read-only access. In the end, that's the most flexible approach, and it doesn't really present much of a downside.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...