[OpenAFS] building swig based interfaces

[Christof Hanke]

On Tue, 3 Sep 2013 08:43:55 -0400
chas williams - CONTRACTOR <chas@cmf.nrl.navy.mil> wrote:

> 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.
>=20
No, it doesn't.

I even started it, but the got distracted.
See=20
http://gerrit.openafs.org/#change,1970
and
http://gerrit.openafs.org/#change,1975

Mea culpa.




> On Tue, 3 Sep 2013 12:29:50 +0000
> Jakub Moscicki <Jakub.Moscicki@cern.ch> wrote:
>=20
> >=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,=E2=80=A6.) =
which directly depend on this output. So practically speaking you are locke=
d-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 a=
bove). The applications don't parse any output directly but depend on the A=
PI which is also sufficiently high-level to be easily applied and understoo=
d as it follows the same logic as the CLI that admins use with a shell.
> >=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