apexdc++ architecture idea

[SMT 0]

what about splitting ApexDC++ into 2 separate parts: daemon (service) and GUI?

daemon will download/upload data and will be easy compiled to linux or other platform with std c++ libs from same sourcecode base.

control must be performed from usual tcp/ip connection, so user can do anything remotely or control downloads on linux server from desktop pc with windows.

gui for simplicity can be started at WINE (some apex mods altered to work in WINE), but later it can be rewritten as native linux application

today ApexDC++ source is already split into 'client' and 'gui' library, but there is no strict interface

it's also could be 2 lib-files for linking with gui 'StrongDC.lib': usual 'client.lib' that after linking creates monolith program and 'client.lib' with stub functions, that connects to real 'client.lib' on other process or remote machine, so it will be compile-time option to create monolithic or modular program

even for windows users separating gui from server code will increase stability

what do you think? too much work?

[almiteycow 0]

This would be the best way of doing it... not the easiest. It'll definitely be taken into consideration. However, at the moment, much of the focus will be directed at making a version of Apex that runs natively in Linux.

EDIT:

This may actually be a good direction to go toward: http://multidcpp.sourceforge.net/

Edited February 20, 2007 by almiteycow

[OCTAGRAM 0]

Like this idea too.

An analogy I have in mind is what would the user experience be if any network program could only function when exclusivelly holding access to network. E. g., user can't run browser and messenger simultaneously. The only way to manage this is to bundle browser and messenger together in a single program.

That's what happening in p2p world (Shareaza is apogee). p2p connection is exclusivelly controlled by a single program, and this program incorporates too many use cases. In a perfecter world I would use Miranda, Pidgin, Colloquy or whatever else plugin for p2p chat. And Virtual Shell Namespace (or GVFS) for browsing files.

My p2p needs are mostly satisfied by greylink dc++. Somehow greyteam manages to both have a sense how things should be done (lots of features missing in ApexDC++ or implemented improperly) and also time and skills to implement it.

But this kind of request is not likely to be done by greyteam.

[Crise 26]

My p2p needs are mostly satisfied by greylink dc++. Somehow greyteam manages to both have a sense how things should be done (lots of features missing in ApexDC++ or implemented improperly) and also time and skills to implement it.

But this kind of request is not likely to be done by greyteam.

Sure they have the skills... they are most adept in violating the GPL license...

[Lee 84]

A sense of how things should be done? They might have the features you need, but they certainly aren't doing it right. And you're supporting them with that.

[Big Muscle 1]

Sure they have the skills... they are most adept in violating the GPL license...

And not only this. One version of greylink I have tried contained some trojan (file was downloaded from greylink website), so users who use this client are really silly.