As is known, the new PartData API is the biggest/hardest part of current short-term roadmap, and it is also the only reason downloading with hydranode is well... less than satisfactory performance. There are a bunch of problems the new PartData API needs to address, so it's taking a while to figure out all the details.

One possible interface candidate can be seen here. It addresses the following problems:

• Used ranges are made objects - they guarantee that the range they correspond to is properly freed when they are destroyed, removing the errors coming from forgetting to unlock things (most thread libraries have similar concept when working with lock objects).
• UsedRangeId/LockId are gone - those were evil, caused programming errors and were crap to handle both internally and externally.
• Hard requirements for using/locking ranges prior to writing is dropped, since some modules might want to bypass those features. This way, the PartData API is no longer intrusive and allows much more freedom to programmer.
• getLeastAvail() concept has been added.

One current problem in the new API is the issue of keeping back references to given-out used ranges. As seen from the above link, the current idea is to use boost::weak_ptr, which is a weak reference to boost::shared_ptr. This way we do not interfere with the automatic destruction of UsedRange objects when they are no longer referenced to by anyone, while still having access to the data (the weak_ptr's expire when the corresponding shared_ptr is destroyed). However, this most likely needs a specialization of RangeList template which handles it properly. Only part of RangeList API needs to be specialized - namely, merge() and erase() methods will be omitted, since those cannot be handled really when dealing with pointer types.

Madcat, ZzZz