Apollon soon in kde-extragear

[Martin Köbele]

> The difference is that KMLDonkey doesn't at any point implement or link to
> any kind of P2P protocol implementation, whereas Apollon has a compile
> time dependency on giFT. KMLDonkey doesn't even require any P2P software
> installed on the same machine to be useful; it's frequently used to access
> a remote mldonkey installation.

yes, Apollon needs gift to be compiled. But it is -  as kmldonkey is -  just a 
client. Nothing else. It also can connect to a remote daemon. 


> KMLDonkey only accesses one thing: an mldonkey daemon. There's absolutely
> no P2P code in KMLDonkey itself. 
same with Apollon.

> > As for the upload, I had a look at kmldonkey and could not suppress the
> > upload sharing.
>
> Unless I misunderstand you completely, doesn't that rather invalidate the
> definition of P2P?
sure, but Apollon is highly configurable ;)



>
> While I (especially after reading the article Waldo mentioned) can't see
> how Apollon would be a legal liability for KDE, I still maintain there is
> a difference between the two: KMLDonkey has no P2P code, and doesn't link
> to any P2P code.
Apollon has no p2p-code. Apollon links to gift because of some 
configuration-file-io-operations, which are not related with any p2p-code.
Actually, we could write our own methods to read and write in gift's 
config-files, but just for the convinience's sake, we use the handy methods 
of gift.

>
> (In fact, I'm not even sure that Apollon does; my understanding of the giFT
> architecture is incomplete, but I suspect the libgift dependency only
> involves the code for interfacing with a remote giFT client. If that is
> so, Apollon's case becomes even stronger.)
we use libgift just to read and write config-files, as just described.
Apollon doesn't need libgift to run as a remote gift-client.

Martin