On Thu, 26 Jan 2006 01:41:59 +0000, Matthew Toseland wrote:
> Possible FCP options on a ClientGet:
>
> offline=true // keep going after this connection closes persist=false //
> don't keep going after the node is restarted remember=false // don't
> remember after completed => won't show up on
> ListRecentlyCompleted (only valid if offline=true)
What happens if someone sets offline=false and persist=true ?-)
It would be better to have a single "persistance" option, with options of
"online" (keep on going until the connection closes), "reboot" (keep on
going until the node is restarted) and "forever" (keep on going after node
is restarted). Having two persistance options ("offline" and "persist") is
confusing and opens possibility for bugs that simply can't exist with a
single option.
For that matter, you could simply have an option to persist until the
specified time, no matter how many times the node is restarted:
"persistance=123456789", where the number would simply be the time in
milliseconds since midnight, January 1, 1970 UTC
(System.currentTimeMillis(), in other words). Simple and completely
unambigious.
After all, if the client wants to have the request persist after it
disconnects from the node, why should it care if the node gets rebooted
between the disconnect and the next connection ?
So, I propose that there's a single option, "persistance" (or
"persistuntil", whichever you think is clearer), which accepts either the
option "connection" to persist until the connection is severed (the
default), or the date it should persist until, in the "milliseconds since
midnight Janurary 1 1979 UTC". Examples:
persistance=connection
persistance=123456789
Coming to think of it, if "connection" is the default, then there's no
reason why "persistance" should accept it - just leave the option off
completely if you want the default behavior.
