Ever-present fields

[Gervase Markham]

In the past, people have suggested that most fields in the Bug object
returned by the HTTP API should be always present.

The idea is that it's easier for an API user to just check for a value
without having to check for existence first. That would mean adding the
following fields with the following default values to every downloaded
Bug object:

     "attachments"            => [],
     "blocks"                 => [],
     "cc"                     => [],
     "depends_on"             => [],
     "flags"                  => [],
     "groups"                 => [],
     "is_cc_accessible"       => "0",
     "is_reporter_accessible" => "0",
     "keywords"               => [],
     "resolution"             => "",
     "url"                    => "",

(This would, of course, increase the size of every object.) However, in
the case of the following fields, which are configurable on/off in
Bugzilla preferences, the API user would still have to check for
existence before checking a value.

qa_contact
classification
target_milestone
whiteboard
alias
see_also
actual_time
work_time
deadline
estimated_time
remaining_time

My suggestion is that the split between these two groups would seem to
most Bugzilla users like an artificial distinction. Given that in the
future, we might make more of the default fields optional or
configurable, it seems wrong to hard-code a list of which fields are
always present in the returned structure.

So my current plan is to only supply fields which have a value. This
keeps data size down and avoids hardcoding "special" lists of fields.
Let me know if you think this reasoning is wrong.

Gerv
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla@...
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

[Max Kanat-Alexander]

On 10/22/2009 09:25 AM, Gervase Markham wrote:
> However, in
> the case of the following fields, which are configurable on/off in
> Bugzilla preferences, the API user would still have to check for
> existence before checking a value.

        Oh, actually, my current goal is to have parameters only control the
UI. They should only affect the backend when there is a really good
reason. So, for example, qa_contact would *always* be returned by the
WebService, even if it's disabled. This allows clients to have a totally
consistent API no matter how the administrator has configured the
system's parameters. It also greatly simplifies our implementation of
parameters (it generally limits them to controlling only templates).

> So my current plan is to only supply fields which have a value. This
> keeps data size down and avoids hardcoding "special" lists of fields.
> Let me know if you think this reasoning is wrong.

        Given the current direction of Bugzilla itself, I'd suggest that it
would be better to just always return the value of every field.

        -Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>