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. > 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. It does not matter if the "official" splitfile scheme is changed, i just want _plain_ and _raw_ r/w-access to keys. 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). And when the external tools break with "modern" splitfiles - that's neither a freenet problem. > (Also, your mail client seems to be breaking the threading for me.) Oh, i am sorry. That must be the topic change i made on my first reply. kmail handles this stuff quite well in most cases. good byte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20100212/495de02e/attachment.pgp>
