Open zenhack opened 9 years ago
If we can use structured JSON, I don't see any good reason to change the fields we have. Just getting rid of the sentinel values should be sufficient, I'd say. (Remember that we want to have access lists too at some point, potentially.)
Quoting George Silvis, III (2015-07-28 17:31:47)
If we can use structured JSON, I don't see any good reason to change the fields we have. Just getting rid of the sentinel values should be sufficient, I'd say. (Remember that we want to have access lists too at some point, potentially.)
Good call --- we could just turn "access" into a list down the line.
-Ian
@zenhack is this still an issue? we now have network_create_simple()
which simplifies some stuff. And did #455 address this issue?
This is still valid. IIRC network_create_simple
existed at the time as well, but it's a band-aid over an underlying ugly api. #455 is orthoginal to this.
The way it is now (with mandatory creator access & id fields, and sentinals for certain values) is an artifact of the fact that we used to use formdata for the API, and of the fact that the CLI can't do structured data or optional arguments. The latter is something we need to fix (and it's actually completely unusable with the recent refactoring changes). We should also simplify this call. Right now you end up passing:
Here's one idea for how to make this a little better (just to get the discussion going, not necessarily attached to this):
access
becomes project. Rather than using the empty string as a sentinel, public networks simply omit the fieldnet_id
is optional --- defaults to allocating (again no more sentinel)creator
just goes away --- if net_id is specified or project is not, it's implicitly an admin-controlled network.Going through each of the use cases described in
docs/networks.md
:{"project": "myproj"}
{"project": "myproj", "net_id": "42"}
{"net_id": "101"}
{}
The "kindof useless, but legal" use case in that document is non longer possible, but I don't think that's a problem.
@gsilvis, thoughts?