[OpenAFS-devel] Patch for XML switch for vos examine

Mon, 3 May 2010 11:29:47 -0400

--Apple-Mail-3-388127569
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Apr 19, 2010, at 9:17 AM, Sanket Agarwal wrote:

> Here's the gerrit change id: http://gerrit.openafs.org/#change,1777
>=20
> Here's the output from my machine:

I've been looking this change over as a guideline to doing a csv version =
of it, and wonder if we're headed a bit down the wrong implementation =
path.

With this patch vos.c now has a series of if-then-elsif sections that =
call a pair of functions DisplayFormatFOO and EnumberateEntryFOO for the =
various FOO output formats. If we ever change/add data, we'll have to go =
into each of these output function types individually and add the =
appropriate changes. To me it makes more sense to call a single pair of =
functions, eg, DisplayByFormat and EnumerateEntryByFormat and hand them =
a flag indicating the desired output format. This will simplify the =
upper levels of vos.c, isolate it from any future format =
changes/additions, and ensures that if any fix/update is made to =
DisplayByFormat or EnumeratreEntryByFormat, all the formats are going to =
be corrected at the same time.

I'm going ahead with a csv patch that mirrors the way Sanket did the xml =
one, but if both are accepted I'll take on the work of refactoring it =
into what is in above paragraph.

Steve=

--Apple-Mail-3-388127569
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><br><div><div>On Apr 19, 2010, at 9:17 AM, Sanket Agarwal =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite">Here's the gerrit change id: <a =
href=3D"http://gerrit.openafs.org/#change,1777">http://gerrit.openafs.org/=
#change,1777</a><br><br>Here's the output from my =
machine:<br></blockquote></div><div><br></div><div><div>I've been =
looking this change over as a guideline to doing a csv version of it, =
and wonder if we're headed a bit down the wrong implementation =
path.</div><div><br></div><div>With this patch vos.c now has a series of =
if-then-elsif sections that call a pair of functions DisplayFormatFOO =
and EnumberateEntryFOO for the various FOO output formats. If we ever =
change/add data, we'll have to go into each of these output function =
types individually and add the appropriate changes. To me it makes more =
sense to call a single pair of functions, eg, DisplayByFormat and =
EnumerateEntryByFormat and hand them a flag indicating the desired =
output format. This will simplify the upper levels of vos.c, isolate it =
from any future format changes/additions, and ensures that if any =
fix/update is made to DisplayByFormat or EnumeratreEntryByFormat, all =
the formats are going to be corrected at the same =
time.</div><div><br></div><div>I'm going ahead with a csv patch that =
mirrors the way Sanket did the xml one, but if both are accepted I'll =
take on the work of refactoring it into what is in above =
paragraph.</div><div><br></div><div>Steve</div></div></body></html>=

--Apple-Mail-3-388127569--