User experience

[forthrin]

amule has an advanced GUI with many features. Meanwhile other file sharing clients/protocols have been greatly simplified recently. IMO, a file sharing client basically needs:

1. Search (name, extension, min. size, min. availability)
2. Adding a download.
3. List of ongoing transfers with download speed and best possible ETA prediction.
4. If it can be determined that a download will never complete, offer the user to cancel it ASAP.

Other relevant factors:

1. Graceful handling of almost-full hard drives.
2. Not downloading certain files in a transfer (not relevant for this protocol AFAIK).
3. Global limits for upload and download.
4. A way to kindly ask users sharing rare files to increase availability.
5. Security.

Has it been considered to shift development into making a very basic client, even a pure CLI/daemon one, or merge development into a simple client such as Transmission?

[BallaMarcell]

I am not an expert for these topics, but here are my two cents considering the factors you mentioned:

1. Such downloads are stopped and an error message is displayed in the log
2. What do you mean by this?
3. You can set both limits in the settings
4. This is done by the auto priority system, but the user can override it
5. aMule has protocol obfuscation, message filters and ip filters among others in the settings

[gonosztopi]

Has it been considered to shift development into making a very basic client, even a pure CLI/daemon one

aMule has both a command-line interface and a daemon.

amule has an advanced GUI with many features. Meanwhile other file sharing clients/protocols have been greatly simplified recently.

Could you please elaborate a bit more on what is not needed in aMule in your opinion?

[forthrin]

I didn't look very closely at the CLI version, but I'll abstain commenting on that for now. I just have a general impression that aMule is a somewhat obscure app for tech-savvy people, ie.

• Dated Win XP-like GUI
• Outdated documentation
• Hundreds of advanced options
• Hard to compile
• A plethora of build components
• Not up to date with OS (OS X)
• Not available as package (Homebrew)

I don't think I ever changed a single preference setting, nor did I chat with anyone or pay much attention to the fancy graphs and statistics being displayed.

Would it maybe be a better use of developer resources to port the protocol into an existing client like Transmission, which has got the balance between features, simplicity and user friendliness just right.

Like I said earlier, file sharing is basically about a good search, good availability checking, good time estimates and a happy little notification when a transfer is complete.

But maybe all these advanced features and the app's eccentric nature is an essential part of the culture around the aMule, and I'm stepping on a few toes now.

[gonosztopi]

Hundreds of advanced options

I don't know what options you consider advanced, but in the "Advanced" section of the preferences there are 5 options.

Dated Win XP-like GUI Outdated documentation

With only two active developers who work on aMule in their free time (besides having a job and a life), it's hard to keep everything up-to-date. You're welcome to contribute some updates to the documentation.

Hard to compile

I didn't notice.

Not up to date with OS (OS X)

Neither of the developers have a Mac. Would you buy me one I make it up-to-date with the latest OSX version.

Not available as package

It is available as a package in most major Linux distributions, there is a Windows installer and an OSX package. What else do you need?

I'd suggest you read a bit on what aMule is, and all your suggestions within those boundaries are welcome.

[BallaMarcell]

I'd suggest you read a bit on what aMule is, and all your suggestions within those boundaries are welcome.

aMule is a fork of eMule. That is why it has all the options it has. If you prefer a different version with different gui and options etc. than you will have to look for (or create) another fork that stays compatible to the other eD2k clients out there.

[tbo47]

I felt the same way as forthrin and started to write a JavaScript client: https://github.com/tla-dev It can connect, start a search, get the list downloaded files. It's very very basic and not really functional. I struggled a lot with the connection and had to read the c++ code. I kind of gave up as Google is giving up chrome apps soon. Maybe I should explore the Cordova project and see if I can do a JavaScript client with it.

@forthrin you can maybe use my code as a starting point. I can also update the amule documentation about how to create a client if you want to develop in an other language. Or I can re develop a client in Java if you want to create an Android client.

[forthrin]

@tla-dev: I'm happy to hear you've been having similar thoughts. Searching, adding, downloading, listing and cancelling is really the backbone of file sharing.

My development has mostly been web-based, not app-based, so I've really no experience with these C/C++ monsters and their complex dependencies and build systems.

However, if there was a REST API towards a running local daemon, or other simple interface to talk to it, a CLI client could be reduced to a few hundred lines of code. Pseudo code example:

if option.prefix "-s" then
  rest.get("http://localhost:4567/search/%s", url_encode(option.argument), on_response)
end

function on_response(response)
  foreach response.items as item
    printf("%2s  %5s  %s\n", item.availability, item.size, item.name)
  end
end

I would actually prefer a CLI-only client. I use CLI-only for torrents. Transmission also has a web interface, but I never use it. Even uTorrent's relatively simple GUI is long abandoned.

How large is the core of aMule that does all the heavy work with exchanging the file pieces? Could this be isolated to a module with a simple API? It would be easier to maintain and compile.

All options could be snugly fit into a UNIX/JSON-based config file. Options are changed once or never. You don't need a great big Preferences window.

If there are only two developers working on this project, I say simplify it to the bone, or port the core protocol code into another front-end (like Transmission).

[gonosztopi]

I would actually prefer a CLI-only client.

amulecmd and amulecmd -c. But beware, some operations require an active connection being maintained (like searching, browsing the results and downloading one of them), so you can use only the first variant (without -c)

How large is the core of aMule that does all the heavy work with exchanging the file pieces?

Look at the sources for amuled.

Options are changed once or never. You don't need a great big Preferences window.

Many of our users have find it hard to look up a folder in their box and edit a text file there. It's easier for them to use a great big Preferences window.

or port the core protocol code into another front-end (like Transmission).

No. Other front-ends may implement their own backends for the eD2k protocol, but it won't be aMule anymore.

aMule is what it is and will stay like this. You don't like the GUI? Use the daemon. You want to use a command-line interface? Use amulecmd. You miss some features from there? Tell us. You want to use another protocol to communicate with the core? Describe your ideas. But we won't abandon this project because you don't like it.

If you have constructive ideas, please share it with us. But words like "simplify the GUI" doesn't have a real meaning behind, please tell in detail what you consider being simplification.

[tbo47]

@forthrin I'm still coding a javascript client for amule. It's 2 parts:

1. amule-js: a javascript/typescript library to discuss with amule. There are a couple of examples written for nodejs. It's very similar to what you wrote in pseudo code. It is usable now.

2. a electron app which is using amule-js. It's not finished yet but can do basic stuffs like searching, show downloads, cancel a download, see the shared list file ... It's written in angularjs 1 and angular-material 1.

[forthrin]

Interesting! What is the simplest way I can install the amule server (only) on OS X? (Since the app only includes the front end) Is there a Homebrew amule-daemon package, for instance?

[HumanG33k]

Sry but for me the only thing is missing in aMule is more developper. For maintain and improve the daemon and amulegui. (seedbox power)

like it says before

[martinvahi]

.... with these C/C++ monsters and their ...

Well, I've done speed optimized C++ for a few years of my life as my main job, image processing for pharma industry, and the C++ is really good for low level, speed optimized things, but anything that is fundamentally dynamic, is pretty much a waste of time to write in any compiled, non-dynamic, language, even if the language is C++, unless there is a REALLY HUGE BUDGET and A LOT OF TIME AVAILABLE. By _a_lot_oftime I do not mean parallel man-hours per team, but man-hours PER SINGLE PERSON.

My summary about GUI-s and programming languages is that back in the day one of my colleagues maintained the C++ based GUI and he re-implemented run-time type inference by storing some string variable with type name and years later, when I as a freelancer worked on 2 different projects, not in parallel, but sequentially, I found out that if I want to have a kind of DYNAMIC 2D GUI that keeps the screen free from all currently unused buttons, links, what-ever-other-elements, then the classical card stack model or the static things that can be drawn with various IDE integrated GUI editors, is so much work that I had to figure out some more clever way, how to manage the work load, specially when working alone as a freelancer. I came up with, after very long experimentation and a long series of mistakes, with a specification that allowed me to at least somehow cope with the task.

Unfortunately I can NOT recommend anybody to use the end result, which as of 2018_12_29 is bitrotting at

https://technology.softf1.com/raudrohi/2013/09_04_v_25/

because it needs a heavy overhaul of coding style and RENAMING of many classes/functions/etc. It's architecture is not fundamentally wrong, but the code needs serious renaming and restructuring, cleanup of old stuff. The messaging that is used by widgets for communicating with each other, needs serious upgrade, the overall idea is right, but the implementation is a confusing mess. It also needs some vital new widgets. I started the upgrade of my JavaScript GUI library by summarizing the lessons learned at

_Raudrohi State Cluster Specification Type 1 (RASTCLSPt1) https://longterm.softf1.com/specifications/rastclsp_t1/index.html

Let's just say, the current mess at my GUI library is "good enough", if I need to do something for a paying client, but the mess is embarrassing and I really want to clean it up. Unfortunately my efforts have been mostly on the packaging and delivery side. I've been trying to write a set of Bash scripts and create a "user space distribution" specification, backed up by actual experiments and Bash scripts, to simplify the creation of virtual machines and Raspberry Pi images.

https://technology.softf1.com/mmmv_distrocomponents_t1/

The aMule came to my attention in the context of censorship resistant operating system distribution package hosting. For example, imagine, what will happen with many Linux distributions, when the central package hosting repositories go down or the malware placement to standard OS packages becomes more than just a law requirement in the U.S. A person, who says NO to the Russian KGB/FSB or the Saudi or Chinese "internal security" officials/goons will be tortured and/or killed, but people need to use computers for learning about the world, even if it is materials about democracy in China, "naked women" in Arab region or what the WikiLeaks distributes at "The Free World", The West. Hence my other project,

(Redirects to a Fossil wiki.) https://silktorrent.softf1.com

The main result of the Silktorrent project is actually a super simplistic idea that if tar-files are renamed according to their size and secure hash, then even enemies can distribute them without having any capability to add malware to them. As long as the tar-files are downloaded through some fine anonymization network like Tor, it does not matter, whether they are served by KGB/FSB, NSA, STASI, whatever "Police" or even the MPAA. A solution like aMule is PERFECT for distributing those tar-files, because the name of the tar-file can be used as the query string of the simple string search. As a matter of fact, I have an idea, how to even build a distributed search engine that can scale to size that is even greater than the current Google data centers are, so may be, if You are wondering about improving the search algorithm of the aMule, You may want to read (and criticize)

https://www.softf1.com/cgi-bin/tree1/technology/flaws/silktorrent.bash/wiki?name=Application+Example:+Distributed+Search+Engine

What makes this idea different from sources of inspiration like the YaCy is that security and bad actors have been counted in from the very start and there is no effort to do classical indexing. I do not want to say anything bad about the YaCy, but it is a fact that everybody stands at the shoulders of giants and YaCy is one VERY HELPFUL and VERY INSPIRATIONAL Giant. It's just that, now it's time to do NEW KINDS OF MISTAKES in stead of repeating the mistakes already done by the Giants that carry us and one of the biggest mistake of the YaCy is that it tries to SOLVE TOO MANY VERY HARD TASKS AT THE SINGLE PROJECT. Namely, reasonable indexing is basically text analysis, linguistics, something that people can spend their whole careers on trying to get right, but all current search engines, including the YaCy, try to somehow offer some very complete and "human-like" search results. It would make much more sense to just admit that text analysis is a separate task and shove it to some other project and focus on other sub-tasks. In that sense the aMule is really nice: simple, "dumb", DISTRIBUTION TASK and some very simple, primitive, search and nothing more.

For example, a distributed search engine could be a totally separate project that uses aMule and may be also some other P2P systems, may be ZeroNet or Dat or IPFS, for distributing the Tar files that have Silktorrent specification based file names

(A Bash script for creating the tar-files. Command line args can be displayed by giving "help", without the quotation makrs, as its 1. command line argument.) https://www.softf1.com/cgi-bin/tree1/technology/flaws/silktorrent.bash/artifact/433efaa35a360ddc

However, there is one fundamental flaw that the aMule currently(2018_12_29) seems to have, I'm not totally sure, whether it has it. Namely, the downloaded files seem to be placed all to a single folder, which means that if the number of files in the folder reaches a few thousand, the file system becomes slow. For example, the Doxygen solves this issue by automatically generating folders that have name lengths of 2 letters and then it distributes the files within those sub-folders. That's how the number of files/folders in every folder is limited and the file system will not become a bottle neck. That is to say, unless aMule does something similar, the aMule will not scale. I'm not sure, how to solve this, if the file names contain hieroglyphs. Probably there has to be some range of characters that will be interpreted as if they were "a", some Unicode code range as if they were "b", some Unicode code range as if they were "c", etc. Easy for me to say here, much harder to code.

Anyways, thank You for reading my comment and the main point of my long comment is that I try to lobby here that the aMule would focus on a FEW THINGS and do them REALLY WELL, so that it could be used as a sub-component at other projects, like the distributed search engine that I'm planning or an operating system distribution package publishing system.

Thank You :-)

[martinvahi]

I like to add that what regards to the current wxWidgets based GUI of the aMule, or at least what is available from the openSUSE package collection, then I see it as a true beauty. I believe that I at least little bit understand that it is horribly hard to create a GUI in C++, even a relatively static GUI, because the dependency hell that starts with OS upgrades is quite hellish, but the end result is sure nice, lightweight, FAST, SNAPPY. A true beauty, specially if compared to anything browser based.

On the other hand, I do consider practicality (speed, low consumption of resources, etc.) more important than artistic values, so I'm probably a very wrong person for any fashion related advice.

[Vollstrecker]

Closing because I don't expect any benefit from here.

[forthrin]

@Vollstrecker: What do you mean by "Don't expect any benefit"? That aMule wouldn't benefit from a simpler GUI, or that there aren't dedicated developers up for the task?

[Vollstrecker]

Both, plus that I read in every second post would should make a cli (which we have already) or integrate it in other apps (just no).

We have a working gui that works, and we have guiless stuff that works for most of the users. We have to fix some things, sure.

But as long as this discussion here draws the same circles, there is no benefit. You can contribute with a design that you like better, and as long as it can live beside the working stuff it'll be integrated, but keep this here as an issue doesn't help anyone.

[forthrin]

@Vollstrecker: I agree. I think the best possibility for a modernised UI is someone forking the protocol code and integrating with the uTorrent or writing something completely new.

Since the network holds a lot of interesting data not available elsewhere, it's just a little sad that it's made largely inaccessible to most people.

But maybe that's exactly what the community finds charming about it...

[martinvahi]

Since the network holds a lot of interesting data not available elsewhere, it's just a little sad that it's made largely inaccessible to most people.

But maybe that's exactly what the community finds charming about it...

@forthrin I do not know about the "community", but without knowing anything about the (a|x|e|whatever)Mule community I can just look at the history of the "internet" and the moment some publishing tool gets popular, there will be the various parasites that see it as something worth exploiting. Think of the various lawyers, patent trolls and supermafiosi("states") that start to rob. The Roman urine tax (archival copy) is a nice example of how in the name of wealth for the robbers any absurdity goes. I think that it's only a matter of time, when people start to pay a special "internet tax" to the supermafia, just like there is an extra tax that is added to gasoline, not to menton the "VAT" on everything.

As of 2019_05 I do not think that the freedom-loving part of the planet Earth population, a very small minority, benefits if the rest that the supermafiosi feed upon, adopt the things that the freedom-loving minority likes to use. In the past I had a different opinion about it. I was thinking about "hiding in the masses" and "mass effect", but now I think that the "hiding in the masses" part works and the attention of parasites out weights the mass effect benefits. So being useless for the parasites is a very good property to have. Less supermafia limits ("legislation").