[OpenAFS] building swig based interfaces

[Jakub Moscicki]

True. On the other hand you should consider that this is a generalised prob=
lem: I bet there are tons of system utilities around (perl,=85.) which dire=
ctly depend on this output. So practically speaking you are locked-in alrea=
dy.

In our case, all parsing is anyway factored out into one single place, so c=
hange may be managed reasonably well (if that change ever occurs - cf above=
). The applications don't parse any output directly but depend on the API w=
hich is also sufficiently high-level to be easily applied and understood as=
 it follows the same logic as the CLI that admins use with a shell.

kuba

--


On Sep 3, 2013, at 2:13 PM, chas williams - CONTRACTOR <chas@cmf.nrl.navy.m=
il>
 wrote:

> 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 completel=
y sufficient.
>> The pathes to those binaries are not hardcoded, but can be changed quite=
=20
>> easily.
>=20
> While sufficient, it does create problems in other ways.  For instance,
> 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