Jump to content

CLI / Headless Support


angelbunny

Recommended Posts

I get that µtorrent is not Open Source and probably will never be, but if you ask the average person why they want µtorrent to be open source is not so they can tweak the lower code but usually it is to script and automate something or make a different front end of some sort or another. Also, the community can help out. If there is a requested feature it can be filled easily and not from an original developer which makes life easy.

So I ask: Why not have the best of both worlds? Any *nix based operating system like OS X has a very powerful shell that can be used in many ways. Why not make a headless libtorrent type of µtorrent version? It is still closed source yet anyone can write a script to make µtorrent do almost anything they want to it. The community could make its own open source gui front end or have multiple to choose from, and there could be tons of add ons like plugins that do different things. I'm not asking to open up the code base but to let µtorrent take advantage of the platform it is on. You can do this with nearly any app on OS X and Linux. Why doesn't µtorrent have a headless / CLI capability that lets the community take control? I would love to write a couple of scripts for µtorrent just like I have for rtorrent. The difference is µtorrent has a native GUI which rtorrent does not, it supports the uTP protocol, and automatic upload rate limiting.

Personally, I'm not interested in changing the gui in any way but if that is the communities interest then why not let them have that ability? If the community wants an httpd for their µtorrent why should the devs have to write it when the community could for the devs? If someone wants a new feature that does not alter the lower code base of µtorrent then why are the devs doing it and not the community?

Why can't I write shell scripts that take advantage of µtorrents power? Why doesn't µtorrent display all of the info in the gui on a text level (logs) that someone could take advantage of to make a different front end? Also, I doubt it would take much work at all to add such a feature. I can understand why a feature like this would be nearly pointless in windows but on OS X (and Linux) I can't understand why it isn't already a feature.

All you would have to do is three things:

1) Output everything that is happening (what you would see on the front end) to a log file. Nothing permanent so the file doesn't grow, just a way for an external source to read this and see what is happening like a script or a separate program.

2) Allow µtorrent to accept CLI commands while running live. This way the scrip or separate program can interact.

3) Give an option for µtorrent to be headless on the CLI level when first running. This way µtorrent could potentially be the engine for a seedbox or an httpd or something else like a separate UI.

Simple, yet powerful.

Please let the community take control.

Link to comment
Share on other sites

See, that I don't get. Much of the applications written for OS X are written with "pretty UI" in mind, and yet, you make it sound as if every single popular application out there has CLI support. Heck, I'm doubtful even half of the more popular OS X applications have full CLI support. If any application that doesn't have full CLI support is useless to you, I couldn't imagine what you chose OS X for (as opposed to some other Unix-like OS).

Just because rTorrent or Transmission does it doesn't mean every application does (or has to). A major difference between rTorrent and µTorrent is that rTorrent was created with CLI in mind. µTorrent was written with balanced and usable GUI in mind (admittedly, it's not quite there yet on OS X, but it's one of the main goals).

Link to comment
Share on other sites

To be fair almost every application worth using outside of windows besides the apps that come with the OS are open source. I'm not talking the heavy duty photoshop type apps but the every day type apps like vlc. So if it is open source that might almost be an apples to oranges comparison. Regardless, looking through my apps folder right now the only two programs that do not come with OSX that I can not script are Skype and µtorrent ... and maybe adium since I've never tried. Everything else in my apps folder I can script and modify to my liking. Really, the only thing µtorrent has going for it right now is the uTP protocol. If it wasn't for that why should people even use it on an OS outside of windows? Maybe because it is easy to setup and has a large name for itself but really other than that... So unless µtorrent can compete with the other clients out there will its user base ever be large enough worth maintaining?

Link to comment
Share on other sites

*shrug*

µTorrent's UI is preferable over Transmission's for many users. Azureus is too bloated for some user's tastes. rTorrent... well, some users prefer GUI over CLI. Xtorrent? Not free, and I can't really comment on its performance or ban status on trackers (I don't know). Different clients have different advantages, and take different approaches to achieve the same (basic) goal of sharing files. You make it sound black and white, which it's not. The entire software ecosystem doesn't need to be homogeneous. We don't do things just because other people do -- we do things because they make sense. Full CLI support isn't a make-or-break feature in our eyes -- µTorrent has always been more than just a good core.

Last I checked, Mac OS X was making inroads because it's "easy" to use (and is supposedly more secure -- won't be touching that subject). If lack of CLI support turns as many users off as you appear to be projecting, then I'm not sure where OS X's ease-of-use claim to victory comes from. Just because you're pretty willing to turn away from µTorrent due to a lack of full CLI support doesn't mean everyone else is going to follow your lead.

The Mac userbase itself is already small relative to Windows, so the potentially small userbase size was something understood and taken into account early on when the decision was made to create µTorrent Mac. Basically, I don't see what you're getting at.

Edit: Better yet, if you're asking why continue if the userbase is going to be so small, then I must ask... how many users do you really believe will use CLI support? Would it really be worth the time to implement full CLI support with such small gains?

No, this isn't an outright rejection of the request -- we're simply saying that it's unlikely to happen any time soon (if ever), and explaining why. Again, the rebuttals here are caused by the fact that you make the lack of a particular feature (x64 support in the other thread) sound like a bigger deal than it really is. Programmability can come whenever WebUI is exposed in µTorrent Mac, and WebUI is on the definitely to-be-done list.

Link to comment
Share on other sites

I'm not a 65 year old grandmother so I do not speak from someone who needs the ease of use aspect. I use OS X over linux because of the gui. Linux is wonderful headless but the second you throw video drivers at it or a front end like gnome or kde it goes from a stable, low resource, secure, and well crafted OS to something that is often less friendly and compatible than windows. OS X has the same power underneath as any linux distro but the front end matches the lower end imho. That is my take on OSX. The whole ease of use thing is for seniors who can't figure out how to check their own email. Most people use windows because they do not want or need that lower end power. Why use OS X if you just want the gui and nothing else? But maybe my views are tainted being in the SF / Bay Area where almost everyone I know uses OS X and does some sort of coding job for a living.

And to get back on topic: I do not believe users will switch to µtorrent for the CLI but the features that are built on top of it that someone else coded. Why use BTG or torrent flux or deluge as a seedbox if the community made a good httpd? Why use transmission or bit tornado or the original bt client or rtorrent when µtorrent could do all of the things those offer? Why use Azureus when µtorrent could have the same content Azureus has in the forum of scripts or a light plugin system that ties to the CLI live.

I had a setup that would auto download what I wanted via RSS through bit torrent as well as http. It would check the free hard drive space and if there was not enough free hard drive space available it would have the bit torrent client stop seeding and then delete the longest seeded content. After the download was complete it would auto extract the content to another folder but first checking for free space again. It then would notify me in a playlist what I had available to watch onto the media center. I used one program to run the scripts in the background, another for rss, another for the http downloads, another for the bt downloads, and another that was the media center software. All of them synced together like a jigsaw puzzle and it always seeded as long as possible based on if I had the free hard drive space. The entire setup took less than a week to manually code and worked well without any issues. It was on a headless box at home running debian.

Long story short: I'm traveling for work and having a server is nice when setup properly but when you're on a laptop and traveling around for work sometimes you wish the programs with front ends had a back end or the programs with backends has front ends. I could do this with azureus but it is a major resource hog and I'm on a laptop. I could do an httpd frontend over the browser but i haven't found anything I've liked. All of the program front ends that work with backend clients are for linux and would use x11 which is annoying.

Because of that conflict I decided to try µtorrent. I figured it would be easier to request backend support then asking the other way around from another client. Also, I really like the rate controls in the client. Everyone I know will not touch µtorrent on OS X with a ten foot pole though and I wouldn't blame them. I think it is the only client on OSX you can't control on the back end.

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...