On Fri, Feb 12, 2010 at 4:28 AM, Martin 'The Bishop' Scheffler <the_bishop at web.de> wrote: > On Friday 12 February 2010 02:35:02 Evan Daniel wrote: >> > ... >> > but anyway, i think it should go to the core functionality of FCPv2. i >> > need to have full control over freenet data without more dependencies >> > than installing fred. >> > >> > good byte >> > >> > p.s. the main reason for this request is that i am disappointed with the >> > splitfile handling code inside fred. and i want to do it better without >> > java ;) >> >> What are you trying to change? ?Splitfile internals shouldn't be part >> of the Freenet API, imho. ?If you're trying to do better reporting of >> the status of blocks to the user or something, then that should be >> added to FCP and exposed, not the internals. > > I want more freedom using freenet. > > One reason for that is the handling of >50 downloads. With so many downloads > in my queue i see they are all hanging around for too long before something > happens - which by other observations seems very wrong. > > Second point is i hate java and want to write some useful software without > hacking on fred. > > Third point is that i want to to implement better splitfile schemes.
I've given some thought to this. See for example: https://bugs.freenetproject.org/view.php?id=2931 https://bugs.freenetproject.org/view.php?id=3370 https://bugs.freenetproject.org/view.php?id=1434 https://bugs.freenetproject.org/view.php?id=3369 What did you have in mind? > >> If you're actually trying to handle splitfiles outside of Fred, I think > that's a bad idea. ?For example, I'm currently working on the math for changes > to the splitfile internals. ?Having external programs in use that hook deeply > into the splitfile code would mean that improving splitfiles would break > things, > which is a bad position to be in. > > For me it is not a bad idea. You don't think having special splitfiles around that can only be read by your software is bad? If there are problems with the current splitfile spec (there are) we should fix them (working on it), not create multiple competing specs that fragment the selection of usable software. > It does not matter if the "official" splitfile scheme is changed, i just want > _plain_ and _raw_ r/w-access to keys. Yeah, support for this is awkward at present. It should be better. Really, Freenet needs a clearly delineated API for external programs (and plugins!). Exposing too little or too much in such an API causes problems, but doing better than the current situation shouldn't be too hard. > Also, code duplication does not look like a problem for developing. The > possibility to implement alternative methods using FCPv2 may even drive > the development. > And by the way: raw r/w-access does not add any hooks and things to the > splitfile handling code inside fred (otherwise, FRED would need refactoring). > If the splitfile handling in fred is changed, fred ought to support the old > encoding scheme for a while (as long it's no change like freenet 0.5 to 0.7). Support for decoding old files has always been the plan, and will continue to be. For encoding support, I agree; see for example https://bugs.freenetproject.org/view.php?id=3381 > And when the external tools break with "modern" splitfiles - that's neither a > freenet problem. Ideally, that's true. In practice, the blame gets assigned to the people who made the change that broke it, not the people who ignored the spec or failed to update their software. At least, that's my experience... Evan Daniel
