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.mosci...@cern.ch> wrote: > > True. On the other hand you should consider that this is a generalised > problem: I bet there are tons of system utilities around (perl,….) which > directly depend on this output. So practically speaking you are locked-in > already. > > 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 the > API which 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 <c...@cmf.nrl.navy.mil> > wrote: > > > On Mon, 2 Sep 2013 14:23:47 +0200 > > Christof Hanke <christof.ha...@rzg.mpg.de> wrote: > > > >> Like Jakub, I think parsing the results of vos, fs commands is completely > >> 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 > _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
