Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[mnagl]

Hello!

I am currently using mldonkey in a LAN with about 40 Users. Now I've heard that aMule performs much better and I would like to give it a try.

But there is one missing feature:
I need a Multiuser Web-Interface like Web-GMUI for mldonkey because I need to know which user started a certain download. I checked the aMule Web-Interface but there is only a two-level-Usermanagement (admin/user) and not a "account-manager" where I can create Accounts for every user. Additionally I need to disable some functionality for the normal users. They should for example be unable to change a downloads priority or stop downloads from other users.

Yours

Matthias

[lfroen]

Similar request appears from time to time. Generaly the answer is "somewhere in the future". The reason is that the problem is not interface, but entire amule datastructure.
The problem begins where user_in_amule != user_in_operating_system. So you need to define you virtual users for amule. Now we need to maintain account/password database, so we can authenticate them.
Next - who owns shared files ? Since amule is not root it can't (and shouldn't) chown them. So they remains under ownership of user who's running amule process.
Add to this all technical issues that will arrive vs. amount of users who need such feature and you'll got an idea why priority of this is so low.

[mnagl]

I think it doesn't need to be this complicated:
Normally it is perfectly Ok if all users share one incoming-folder and can access the files. So what remains is a user-database where gui-permissions are saved and a modified logging mechanism that logs which downloads were started by a certain user.

For mldonkey there exists for example an external gui (web-gmui) that implements the user database via php/mysql. the only problem for this extension is that mldonkey changes all download-ids that it reports to clients after every restart. so the logs become useless. but it shows that such a user-management is possible without even changeing the core of the p2p-application.

the file-permission problem (that doesn't apply to me) is solved in this extension by not giving direct access to the incoming folder but generating the donwnload-list with help of the database and only showing files that belong to the logged in user.

Yours

Matthias

[lfroen]

implements the user database via php/mysql.

mysql ?! Overkill would not be an understatement here. I will not even bother to explain why  it is wrong. Install mysql for list of users ?

but it shows that such a user-management is possible without even changeing the core of the p2p-application.

You did not read anything I wrote, didn't you ?

the file-permission problem (that doesn't apply to me) is solved in this extension by not giving direct access to the incoming folder

You missed the point again.

Ok, I will emphasize my point: you can't ask users to install php and/or mysql (please, no discussion about it). So, file ownership _should_ be maintained in the amule core. And propagated to any remote control interface amule have: remote gui, webserver, amulecmd.

[mnagl]

I didn't want to propose using mysql. It is used in the described web-gmui because mldonkey also doesn't support user management and so the support for it is built "around" the mldonkey core with immense effort. I think this is an evidence all alone that many people need such functionality:
http://web-gmui.sourceforge.net/

Yours

Matthias

[lfroen]

mnagl: I have expressed my opinions. You have different, and want to build user management around amule core. You welcomed. Amule have well defined and good documented EC interface together with working examples.
Good luck in proving me wrong.

[mnagl]

You misunderstood my post. I meant the build-around solution is a bad and desperate solution. Tha fact that there are people even trying that is a proof that I am not alone missing a real multiuser P2P client. The only point where we don't agree is the importance of this feature.

greets

Matthias

[lfroen]

I meant the build-around solution is a bad

Ok, so we back to built-in solution. Which is complicated. And not so importent in my opinion.
Why - because number of potential "customers" is diminishing small. I'm not gonna tell you - "hey, you don't really need it". What I'm telling here is that there're more importent things to do (like kad, remote gui, good webserver, bug fixes).
It's about order of priorities.