Print

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

[sokod]

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.

[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.

[Diesis]

I agree with this feature request.

[JonathanShields]

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.

[Kry]

It could be done someday. Meanwhile, let's improve aMule. Maybe someday we'll be all SD devs, we're good friends anyway.

[Diesis]

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:.

[Kry]

it will be done that way yes. but not yet

[lfroen]

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.

[sokod]

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!!

[Kry]

Thanks!

[lfroen]

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

[Kry]

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

[lfroen]

My question is: will you accept patches that addressing those issues ? Against what version ?

[Xaignar]

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?

[lfroen]

Is there any reason why browsing cvs thru browser (web-cvs) is disabled ?