On Saturday, October 26, 2013 09:11:03 PM Matthew Toseland wrote:
> The initial state could be huge. 

Yes. But it really depends on filters set on subscriptions, which are not 
implemented yet though. A client might filter the "Identities" subscription to 
"only own identities", then it wouldn't be very much.

Also, you should keep the following in mind: In the near future, I should 
implement "persistent" subscriptions. Persistent in our case means that you 
can restart WOT or the client which filed the subscription WITHOUT re-creating 
a fresh subscription, and therfore WITHOUT a new synchronization of the 
database content. While WOT is running but the client is not connected, WOT 
will just continue storing events for it, up to a certain timeout of lets say 
1 hour, after which the subscription will be killed. So when the client 
reconnects, synchronization of the initial dataset does not have to happen 
again. It can instead just send out all events which happened while the client 
was offline.
This should be sufficient to guarantee that in normal operation of a node, 
there 
will only be ONE synchronization of the database per plugin - when loading it 
for the first time. Downtime of plugins typically only happens when the node is 
restarted or a plugin is updated, and it shouldn't be more than an hour I 
guess.
The bugtracker entry for that is here: 
https://bugs.freenetproject.org/view.php?id=6113

> 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?

> 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.

> or (probably better) put it in a Bucket i.e.
> a data field.

Which storage format should I use then?

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?
_______________________________________________
Devl mailing list
[email protected]
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Reply via email to