On Thu, Aug 20, 2009 at 1:40 PM, Evan Daniel<[email protected]> wrote:
>>> >> If that's the case, we could consider instead the changes I propose in
>>> >> 3359 / 3371 (combined with a recommendation that client apps insert
>>> >> uploaded files to SSK keys, with the SSK keypair used for many files
>>> >> or only one, as appropriate).  If SSKs are really that much
>>> >> longer-lived, they would provide a more reliable solution the
>>> >> multiple-CHK style MHKs.
>>> >
>>> > 3359: this is a bug, unless a MIME type has been set. We can fix it even 
>>> > when there is a MIME type by making ?type= a proper part of FreenetURI's.
>>>
>>> My point with 3359 is that this is a good idea even if the MIME type
>>> has been set, and even for manifests etc.  Ideally it would be
>>> combined with some other changes, and the SSK block would just hold
>>> splitfile metadata for a layer with 15 data + 15 check blocks, and the
>>> MIME type and manifest and such would be in a redundant layer to leave
>>> the most space in the SSK block so the top splitfile layer would be as
>>> large as possible.
>>
>> Yes, and I was under the impression that we already put the splitfile 
>> metadata in the top SSK block if it fits. If we don't that is definitely a 
>> bug. Not sure what you're talking about with manifests - if it's a normal 
>> manifest the data should go in the top block, if it's a container then the 
>> splitfile for the container should go in the top block.
>
> I'll check this.

It looks like the bug is real.

See:
freenet:s...@jmhzpx0ns2r6hei8h5eqoofx4y2vzsp2yv5xqa0xmbw,vy7XYlguseWGqOztkFo~XvOUh3ScOKMgJhhknWKx7aY,AQACAAE/yatest-0/
freenet:s...@jmhzpx0ns2r6hei8h5eqoofx4y2vzsp2yv5xqa0xmbw,vy7XYlguseWGqOztkFo~XvOUh3ScOKMgJhhknWKx7aY,AQACAAE/yatest-1/

The first has only a medium-sized bitmap; the second also adds a tiny
text file.  In both cases, the compressed data fits in 4 data blocks
(8-block splitfile).  I believe that metadata ought to fit in a 1 KiB
SSK key (8 * 69 = 552, should leave plenty of extra space for whatever
else is needed).

We need a better KeyExplorer type thing, because I'm not entirely sure
what's going on or how to figure it out.  I don't know of a way to say
"what's stored in this SSK key, and what CHK key(s) does it
reference?" and then repeat the question for CHK keys, splitfile
layers, etc.

I didn't pay close enough attention on the first insert.  When
inserting the second, it started by showing 8 blocks to insert (the 8
splitfile CHK blocks).  It then transitioned to showing a total of 9
blocks, then 10.  That sounds to me like 8 splitfile blocks + 1 CHK
splitfile top block + 1 SSK redirect block.

Evan Daniel
_______________________________________________
Devl mailing list
[email protected]
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Reply via email to