Including and excluding fields

Gervase Markham gerv at
Fri Jan 15 21:14:54 UTC 2010

On 15/01/10 06:09, Max Kanat-Alexander wrote:
> 	This is a reasonable idea--it does accomplish something I was thinking
> about, which is including extra fields in addition to the default
> fields, which I was going to accomplish by an extra_fields argument, in
> XML-RPC. I tend to prefer not overloading things with two meanings (in
> this case, "fields" means both "add this" and "keep this")--I think it's
> a little simpler to just have a separate param. But it might be simpler
> from an implementation perspective to just have "fields"--I actually
> don't know.

It would be good if the result of this discussion was the emergence of a
consensus on how to do it, and then both implementations could converge
on it (even if XML-RPC had legacy additional capabilities).

> 	Thinking about some use cases briefly, I suspect that "fields" would be
> easier for consumers, though I worry that it would be somewhat unclear
> and confusing when reading API documentation.

You mean the "add these" model would be easier for consumers?

> 	If you do stick with this, I'd use "_default" instead of "all", though,
> since I'd interpret all to mean "every single field possible".

"all" _does_ mean "every single field possible". Perhaps what I wrote
above was unclear. Let me try again:

fields=<comma-separated list>|"all"

If the value is a list, then those fields are _added_ to the default set
to produce the set returned.

If the value is "all", then every possible field is returned.

dev-apps-bugzilla mailing list
dev-apps-bugzilla at

More information about the developers mailing list