On 02/06/2013 12:14 PM, Sage Weil wrote:
On Wed, 6 Feb 2013, Dimitri Maziuk wrote:
On 02/06/2013 01:34 PM, Sage Weil wrote:
I think the one caveat here is that having a single registry for commands
in the monitor means that commands can come in two flavors: vector<string>
(cli) and URL (presumably in json form). But a single command
dispatch/registry framework will make that distinction pretty simple...
Any reason you can't have your CLI json-encode the commands (or,
conversely, your cgi/wsgi/php/servlet URL handler decode them into
vector<string>) before passing them on to the monitor?
We can, but they won't necessarily look the same, because it is unlikely
we can make a sane 1:1 translation of the CLI to REST that makes sense,
and it would be nice to avoid baking knowledge about the individual
commands into the client side.
ceph osd pool create <poolname> <numpgs>
vs
/osd/pool/?op=create&poolname=foo&numpgs=bar
or whatever. I know next to nothing about REST API design best practices,
but I'm guessing it doesn't look like a CLI.
sage
Well we could easily package, say, "mon getmap" into a json
vector-of-strings for transmission as the http payload of the PUT
request, *or* encode them as a simple "s1=mon&s2=getmap", but again, the
data format is so simple that I'm not sure it buys much. We definitely
want all the interpretation centralized in the daemons, I think, so this
is just string marshalling however we choose to do it.
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
