aMule Forum
English => Feature requests => Topic started by: sokod on March 27, 2004, 08:09:08 PM
-
Sorry if this feature have already supported by aMule.
Well, i think an amule client daemon and amule interface for terminal would be a good idea for people with one server on their LANs so they could to run an amule interface for terminal and connect with amule client daemon in order to handle it. The amule client daemon should have support for web server administration, user accounts and user priorities. Each user could connect to amule client (by terminal, gui or web interface) daemon to add and administer their downloads.
-
The feature you're requesting is being worked on ShareDaemon. It would be GREAT but, as aMule is based on eMule, and eMule's design is not great, core and GUI cannot be easily split.
ShareDaemon is (wishes to become) eMule, designed in a way that allows plug-ins. GUI could be one of those plug-ins.
SD is the (beautiful) future, and aMule is the present. An excelently supported present, by the way. :)
-
I agree with this feature request.
-
I'd like it also. But it requires to rewrite completely, from scratch the client.
A lot of work, being done on ShareDaemon. Search for it on SourceForge. And help, if you are so interested. :)
-
It could be done someday. Meanwhile, let's improve aMule. Maybe someday we'll be all SD devs, we're good friends anyway.
-
May be an extension of amulecmdDLG, a simple parameter to launch amule without displaying nothing (null display ?() ike:
# amule --no-x
and after use amulecmdDLG or amulecmdWEB to connect to it ...
For me will be enough practical :rolleyes:.
-
it will be done that way yes. but not yet :)
-
Originally posted by JonathanShields
The feature you're requesting is being worked on ShareDaemon. It would be GREAT but, as aMule is based on eMule, and eMule's design is not great, core and GUI cannot be easily split.
ShareDaemon is (wishes to become) eMule, designed in a way that allows plug-ins. GUI could be one of those plug-ins.
SD is the (beautiful) future, and aMule is the present. An excelently supported present, by the way. :)
SD seems a very distant future - just by looking to their code ...
imho it is not that impossible to split *mule into daemon and client.
-
for answer to my post so i didn't know ShareDaemon project and now i'll see it. Anyway, im going to continue supporting and testing this project because it is the best p2p client for GNU/Linux and i like it much.
My congratulations for all amule team!! :)
-
Thanks!
-
After reviewing lates cvs snapshots I can tell that amule can be relatively easy split to core and gui.
The only requerements is that core will remain wx-based - since all socket, strings and many low level classes (like list and hash) are wx-based.
Considering this, changes in present code will remain minimal and will contain following changes:
1. removing references to gui elements from protocol and data code.
2. stop using gui elements (controls) as containers for data structures
3. remove window-based messages
-
we know. The state of current cvs is like it is because we're already doing that. but we have unicode to finish first.
Anyway, there are structural changes to the app to be done. Too indeep into the code to tell here without a incredibly complex discussion about *mule codebase :)
-
My question is: will you accept patches that addressing those issues ? Against what version ?
-
Of course we will accept patches, provided that they dont break too much at the same time. ;)
It would probably be best to do it against the cvs snapshots.
Why dont you get on irc and meet us in #amule on freenode.net?
-
Is there any reason why browsing cvs thru browser (web-cvs) is disabled ?
-
That would probably be because that CVS server isn't up to date, so users shouldn't use it anyway. We currently use a private CVS server, but you can probably get read-access to that. I'll ask the other devs if they're ok with that, but I cant see why not. Otherwise, you can use the cvs snapshots here: http://amule.hirnriss.net/
-
Originally posted by lfroen
My question is: will you accept patches that addressing those issues ?
so you seem to be determined to create a gui/core version of amule, thats great :D
i hope to see some patches and/or binaries to help testing the result :)
-
Those are very sensitive changes and so they will be reviewed in deep. :)
-
I hope so.
I will split changes to smaller patches to target specific things like logging, notification, status updates, etc.
-
Well, i think an amule client daemon and amule interface for terminal would be a good idea for people with one server on their LANs so they could to run an amule interface for terminal and connect with amule client daemon in order to handle it. The amule client daemon should have support for web server administration, user accounts and user priorities. Each user could connect to amule client (by terminal, gui or web interface) daemon to add and administer their downloads.
Currently, you can run aMule on a server and export display to an X client on your computer. That's not as great as what ShareDeamon should look like as it is not multiuser, not a deamon and demand an X server running on the server but it's available.
-
Originally posted by futal
[
Currently, you can run aMule on a server and export display to an X client on your computer. That's not as great as what ShareDeamon should look like as it is not multiuser, not a deamon and demand an X server running on the server but it's available.
I know, and you can do it with VNC X server too. But this is pretty complicated setup and as you pointed not multiuser. ShareDaemon is so far away from amule considering feature set and status of code, so I can't see how it will replace amule.
-
aMule IS multiuser.
and that's a fact ;-P
but code and gui are the same code.
Greetings
-
Originally posted by Jacobo221
aMule IS multiuser.
and that's a fact ;-P
but code and gui are the same code.
Greetings
I disagree. aMule doesn't distinguish between downloads of different users. Or you mean something else by "multiuser". Making it accessable by anyone doesn't make it "multiuser" :)
core and gui is not the same code - it just references one another :)
-
I mean that each user can run _one_ and only _one_ aMule instance. That's enough to bemulti-user. Each user has it's own Inc and Temp dirs. System administeators must have already take care so that two users don't use the same directories at the same time.
I don't see what you are trying to explain, btw,
Greetings
-
maybe it would be a good idea to split amule in 2
1- daemon that manges the ul/dl by using amule files - this part doesnt need a gui so it can be done
2- a gui prog to search and mange d/l u/l and configurtions
alittle rearange of the prog and you can enjoy both worlds :)
asuming it solves the problem :) it sounds good to me
-
that's exactly what is splitting gui-core is about. core must mng files, up-downloads, bandwidth limits etc, and gui must just mostly setup options and see status
-
:O
wow was i sleepy when i posted the last massage....
sorry didnt see there were 3 pages here :)
anyway spliting it would be grait and its the way to go as i see it
also i'll see what i can do with the sorce to help....
(its been a while since last time i wrote a sorce code.... :( )
keep up the good work
:baby:
-
Yeah, the Museek guys did an excellent job separating GUI and Core of Soulseek, take a look:
http://museek.thegraveyard.org/
Something like that would be awesome! :rolleyes:
-
Will wait :)