Oh, before anyone starts to use that t=mkdir plus children= API I added a few days ago.. be aware that I'm going to change the name in the next few days. While discussing it with Zandr last night, we realized that it'd be safer to give it a new name, rather than to add a new argument to the old name. The problem is that an old client node will ignore the children= field, and the webapi user of that node won't have an easy way to find out whether this node is the type that recognizes the new field or not (short of trying it and then listing the newly-created directory to see whether it's empty or if it has the requested children).
So instead, I think this will be done with POST /uri?t=mkdir-with-children , an entirely separate verb. t=mkdir will continue to ignore the request body and create empty directories. And when DIR2:CHK is ready, the verb will be t=mkdir-immutable-with-children or so (instead of t=mkdir&immutable=true, which would suffer from the same problem). I think we have one other place where this was an issue, when you upload a new file and can add mutable=true to get a mutable file instead of an immutable one, but I think that this functionality has been around long enough that there's not a serious concern about whether the node will pay attention to the argument or not, plus it's trivial to check the response to see that it's SSK: instead of CHK: or LIT: . So I don't think I'll be changing that one, even if the result is a slightly non-uniform API. cheers, -Brian _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
