> a) So if I take a key value and insert exactly one byte of data for it, that > data will never expire? What if I flood Freenet with thousands of one byte > inserts? Will they be blocking datastores (which are limited by number of > entries as well) and never be cleared?
This may be an issue, but this is why the piece of data is placed *above* the last piece of data which would have increased the total length of the data "before" the place that the data is inserted over the length of the data (poor description - but you know what I mean). The primary limitation in datastores is the byte length for the data, since datastores could be extremely long in terms of the number of items they permit, still, perhaps this algorithm should be modified to accomodate this. I will have a ponder about how this can be achieved. > b) Isn't this a little risky do right before a release without > testing as to the effects? Well, I assumed that since very significant modificactions were made to the CVS tree in the last few days (in terms of the new key architecture) that we would be postponing the release anyway, but if you are confident that the release is still on-track then we can easily back-out this change until after the release. > c) You'd need to make sure searchData() does the same thing (if you want it > too). Hmmmm, I assumed that searchData() would use the put() method, but I will check this. Ian. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20000807/a559d729/attachment.pgp>
