[OpenAFS] building swig based interfaces
Tue, 3 Sep 2013 15:00:31 +0200
On Tue, 3 Sep 2013 08:43:55 -0400
chas williams - CONTRACTOR <email@example.com> 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.
No, it doesn't.
I even started it, but the got distracted.
> On Tue, 3 Sep 2013 12:29:50 +0000
> Jakub Moscicki <Jakub.Moscicki@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,=E2=80=A6.) =
which directly depend on this output. So practically speaking you are locke=
> > 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.
> > kuba
> > --
> > On Sep 3, 2013, at 2:13 PM, chas williams - CONTRACTOR <firstname.lastname@example.org=
> > wrote:
> > > On Mon, 2 Sep 2013 14:23:47 +0200
> > > Christof Hanke <email@example.com> wrote:
> > >=20
> > >> Like Jakub, I think parsing the results of vos, fs commands is compl=
> > >> The pathes to those binaries are not hardcoded, but can be changed q=
> > >> easily.
> > >=20
> > > While sufficient, it does create problems in other ways. For instanc=
> > > 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
> > > OpenAFSfirstname.lastname@example.org
> > > https://lists.openafs.org/mailman/listinfo/openafs-info