On Wed, Feb 6, 2013 at 12:14 PM, Sage Weil <sage@xxxxxxxxxxx> 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. I disagree and am with Joao on this one — the monitor parsing is ridiculous as it stand right now, and we should be trying to get rid of the manual string parsing. The monitors should be parsing JSON commands that are sent by the client; it makes validation and the logic control flow a lot easier. We're going to want some level of intelligence in the clients so that they can tailor themselves to the appropriate UI conventions, and having two different parsing paths in the monitors is just asking for trouble: they will get out of sync and have different kinds of parsing errors. What we could do is have the monitors speak JSON only, and then give the clients a minimal intelligence so that the CLI could (for instance) prettify the options for commands it knows about, but still allow pass-through for access to newer commands it hasn't yet heard of. -Greg -- 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
