On Friday 12 February 2010 13:46:42 Evan Daniel wrote: > 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...
Agreed. IMHO it would be inappropriate to make it easy for third party plugin authors to create bogus metadata. If you *really* want to be able to create stuff with arbitrary metadata you can use binary blobs. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20100212/8957a584/attachment.pgp>
