Does this support downloading a single file from both bittorrent and edonkey at the same time? (which is the whole point of the core I presume)
 

What about assigning priorities to each file separately?

About next network implemented... What about Ares and DC++? And usenet?
 

"Does this support downloading a single file from both bittorrent and edonkey at the same time? (which is the whole point of the core I presume)"

Yes

"What about assigning priorities to each file separately?"

Each file is handled as a separate download at core level, so all normal operations are allowed for each single file in the torrent, including pausing, canceling, resuming, and ofcourse, setting priorities (altough currently, hydranode doesn't support downlaod priorities).

"About next network implemented... What about Ares and DC++? And usenet?"

It's a bit early to think about that right now, considering that BT still needs a lot of work, we'r missing peer exchange, and DHT. However, the next network, once we get there, will be one of the mp3-nets - whether it'll be ares or Gnutella or something else is still open. Most likely path is that we focus on user interface for a while after BT, and then (or at same time) implement one of the mp3-nets.

Madcat.
 

Ares has many things in common with Gnutella, so probably implementing one could make a lot easier implementing the other (remember about the benefits of C++ ;))

http://www.answers.com/topic/ares-galaxy
" Because Ares and Gnutella both use the same hash function to uniquely identify files and giFT can also connect to the Gnutella network, giFT users operating both plug-ins can swarm downloads from both networks simultaneously."
 

Personally, I think is too early to focus on user interface, the next networks will change a lot many aspects of user interface design. I think it's better implementing several more networks before focus on user interface, then there will be a very different background of networks for developing a really flexible and thinked for the future GUI ;)
 

"Personally, I think is too early to focus on user interface, the next networks will change a lot many aspects of user interface design."

Yes, I agree. I think there should be another "searchable" network (and I prefer Gnutella since it offers many files + fast downloads), because designing a search window with only one "searchable" network could make things difficult for future.

But on the other side: many people avoid an application without graphical user interface (especial windows users).
 

Please not think that is more important to have more users using hn, fist is more important other design issues, in the start users isn't the most important thing in this kind of ambitious projects. And more networks supported will help even more to having more interested users after having a usable GUI...

My idea is:

* Perfecting internal design all time. Think about not only doings things running the best possible all time (that is very important) but doing easier the development of the project and understanding of the source code at same time, I mean really proffesional & extremelly correct coding. This will attract a lot of developers interested in P2P development. It's needed too being too careful about the code quality, a lot of projects has a bad code quality with the time (and started with incredibly great code).
* Implementing am important number of technically very different networks and think widely open about implementing more networks (not only thinking about users quote, but technological interest too...).
* Provide extensive documentation, both in separate correctly explained technical (and less technical) documents and source code. Improving documentation all time but remembering is more important quality than quantity.
* Designing heavily thinked UIs (http/wml, GUI...), not only copying the look'n'feel of others, but thinking of original ideas and doing easier the use of those programs, even for newbies to experienced users (easy to use, easy to configure, and easy to configure in a expert manner too).
 

" Please not think that is more important to have more users using hn [...]"

More users means more opinions on new ideas/existing features. More users means more feedback! That's very important IMO.
Sure, there shouldn't be made a kludgy GUI just to get more users.
 

"Does this support downloading a single file from both bittorrent and edonkey at the same time? (which is the whole point of the core I presume)"

"Yes"


How does this work? If I download a file from edonkey (FILEX), but a torrent is offering BIGFILE which happens to contain FILEX within it in a subdirectory, what type of verification is there that it is the same file? Can the user force it to be recognized as the same file (same size I guess)?
 

File size, or user forcing it, is not sufficient to allow such downloading, since both can be faked / be wrong. Only basis on which such multi-net downloads are allowed is when hashes match (for example, if torrent has ed2k hashes in it, then we can say for sure that it's the same file).

Aquiring those hashes for multiple networks is tricky, but the solutions have been designed over a year ago on how to do it - all that we need right now is more networks support (including finishing BT), so we can put that design to work eventually.

Madcat.