[OpenAFS] building swig based interfaces

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

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=

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.



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

> On Mon, 2 Sep 2013 14:23:47 +0200
> Christof Hanke <christof.hanke@rzg.mpg.de> wrote:
>> 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=
>> easily.
> 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