On 30/10/13 00:11, xor wrote: > On Saturday, October 26, 2013 09:11:03 PM Matthew Toseland wrote: >> The initial state could be huge. ... Skip discussion of filters, which are of course absolutely vital ... >> Please don't send it as part of the FCP >> message's SimpleFieldSet. > Do we currently have a limit on the size of a SFS? They are generally parsed and kept in RAM, at least until we send them. >> Either split it up into multiple messages >> (e.g. one per identity; but then make sure there is some way of telling >> that you got all of them), > Would be tricky because the synchronization should be an atomic operation > which guarantees that the client is in a synchronized state after it :| It > might be easy using multiple synchronous FCP calls, but I'm reluctant to > change it since it will overcomplicate a lot. Right, hence the second option ... >> or (probably better) put it in a Bucket i.e. >> a data field. > Which storage format should I use then? Another SFS of course! > We use SFS because it allows easy implementation of clients since it is human > readble. Do we have something similar which can be shoved into buckets? > > Could we do 1 SFS per Identity and shove multiple SFS into the Bucket? > > Would suck a bucket be obtainable by FCP clients which are not directly > compiled against fred but connected via network only and written in a > completely different language? You can shove a single SFS or a series of SFS's into a Bucket. Just make sure you standardise the charset. I recommend a series of SFS's rather than a single SFS since the current Freenet SFS code will read the whole thing into RAM.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
