[gdal-dev] Motion: Adopt RFC 29: OGR Set Ignored Fields

[Ragi Burhum]

>
> Martin Dobias wrote:
> > Hi,
> >
> > As there have been no further comments on RFC 29, I would like to call
> > for vote on it:
> >
> > http://trac.osgeo.org/gdal/wiki/rfc29_desired_fields
>

I hesitated whether to reply to this or not. I am aware that I can
(deservingly) get publicly castrated for chiming in now instead of a
couple of weeks ago. In my defense I can tell you I get digests and
then read them when I have free time. Which is usually at the end of
the week. Like right now. Sigh.

Thus, it may be too late already. I know.

I also realize that I don't have voting power on this, but I still
wanted to gave my opinion because I do care about this library. Very
much actually. Feel free to dismiss this as noise.

There are two elements of this RFC that I think are not ideal.

One is the lack of a TestCapabilities feature so I can decide whether
to use this or not. I saw that other people had expressed their
opinions about it and I assumed it was going to be added. Looking at
the RFC, I don't see that this materialized.

The other, IMHO more importantly, is the issue of specifying **what I
want** (SetDesiredFields) vs specifying **what I don't want**
(SetIgnoredFields). I guess the conversation turned to using
SetIgnoreFields after Frank expressed a preference for
SetIgnoredFields here

http://lists.osgeo.org/pipermail/gdal-dev/2010-July/025487.html

Frank's opinion was: "What if it was determined at some point that
fetching the real FID was sometimes expensive and that in cases where
it does not matter we would like to be able to skip that. Should we
then start dropping the FID for everyone who has ever used
SelectFields() without knowing that some day FID would become
optional? I can live with SelectFields(), but to me it is an approach
at odds with trying to ensure backwards/forwards compatability for
applications."

I humbly disagree that this is a strong enough argument to go the
"ignore fields" approach.

With every single other data abstraction library I ever worked with
(sadly, I have used too many), I usually ask the API *for I what I
want*, and the data abstraction library returns to me that content. In
subsequent versions those APIs, there may be optimizations done here
and there, but the backwards compatibility is retained by continuing
with the same behavior.

If there is some optimization in the future (i.e "FID retrieval is
expensive"), and I want to take advantage of it, then I have to use
the new approach (i.e "not including FID" in my request). If I don't,
my code still works, but I am not taking advantage of the new
optimization, right?

Presumably, if I had asked only for what I needed - and I included
FID, it is because I needed it in the first place, right? If I didn't
need it, I would not have requested it in the first place and I would
get the optimization for free in the future.

Contrast this with the other approach, "explicitly express what you
don't want". I know I only need three fields for my calculation, I
request those. New fields are added. In every subsequent version I can
potentially be getting extra fields that I don't need. So then I need
to go back to my code and exclude newer fields I don't want so I only
get what I need for my calculation. Sounds silly, right? I believe
Martin had it right when he expressed his opinion about this.

Martin has rewritten the RFC to be SetIgnoreFields instead of
SetRequiredFields and I feel like a jackass for providing input so
late. I apologize Martin.

But of course you are all free ignore this as noise as I said earlier.
Then I wouldn't be such a jackass I guess.

my two cents,

- Ragi