[OpenAFS] building swig based interfaces

[chas williams - CONTRACTOR]

Yes, I certainly believe there is an existing base that currently
prevents any change.  But that doesn't mean we have to keep letting
this happen.  Creating an admin API library would be nice but not
doable in the short term, but adding XML output to the commands for
others that wish to parse output doesn't seem ridiculous.

On Tue, 3 Sep 2013 12:29:50 +0000
Jakub Moscicki <Jakub.Moscicki@cern.ch> wrote:

>=20
> True. On the other hand you should consider that this is a generalised =
problem: I bet there are tons of system utilities around (perl,=85.) whic=
h directly depend on this output. So practically speaking you are locked-=
in already.
>=20
> In our case, all parsing is anyway factored out into one single place, =
so change may be managed reasonably well (if that change ever occurs - cf=
 above). The applications don't parse any output directly but depend on t=
he API which is also sufficiently high-level to be easily applied and und=
erstood as it follows the same logic as the CLI that admins use with a sh=
ell.
>=20
> kuba
>=20
> --
>=20
>=20
> On Sep 3, 2013, at 2:13 PM, chas williams - CONTRACTOR <chas@cmf.nrl.na=
vy.mil>
>  wrote:
>=20
> > On Mon, 2 Sep 2013 14:23:47 +0200
> > Christof Hanke <christof.hanke@rzg.mpg.de> wrote:
> >=20
> >> Like Jakub, I think parsing the results of vos, fs commands is compl=
etely sufficient.
> >> The pathes to those binaries are not hardcoded, but can be changed q=
uite=20
> >> easily.
> >=20
> > While sufficient, it does create problems in other ways.  For instanc=
e,
> > the output of the commands can never be changed (even in slight ways)
> > since we have no idea how robust your parser might be.
> > _______________________________________________
> > OpenAFS-info mailing list
> > OpenAFS-info@openafs.org
> > https://lists.openafs.org/mailman/listinfo/openafs-info
>=20